ibm db2 - blue medora · 3 blue medora vmware vrealize operations management pack for ibm db2 user...

VMware Vrealize operations ManageMent pack For

IBM DB2

User Guide

2 Blue Medora VMware vRealize Operations Management Pack for IBM DB2 User Guide

NOTE: This document supports the version of each product listed, as well as all subsequent versions, until a new edition replaces it.

You can find the most up-to-date technical documentation on the Blue Medora support site at: http://support.bluemedora.com.

The Blue Medora website also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected].

1. Purpose...................................................................................................................................................................... 32. Introduction to the Management Pack....................................................................................... 3

2.1 How the Management Pack Collects Data............................................................. 32.2 Data the Management Pack Collects........................................................................... 32.3 Inventory Tree (Traversal Spec)........................................................................................... 3

3. Dashboards............................................................................................................................................................ 43.1 DB2 Overview....................................................................................................................................... 43.2 DB2 on VM.............................................................................................................................................. 53.3 DB2 IOPS.................................................................................................................................................. 63.4 DB2 Top-N Queries......................................................................................................................... 7

4. Views............................................................................................................................................................................. 85. Reports....................................................................................................................................................................... 96. Alerts..........................................................................................................................................................................107. Analysis Badges.............................................................................................................................................108. Troubleshooting the Management Pack................................................................................11

8.1 Troubleshooting an Adapter Instance.......................................................................118.2 Testing Connection Failures................................................................................................118.3 Viewing System Log Files.....................................................................................................12

9. Appendix I: Metrics.....................................................................................................................................1310. Appendix II: Alerts.....................................................................................................................................2011. Appendix III: Capacity Definitions.............................................................................................29

taBle oF contents


1. purposeThe Blue Medora VMware vRealize Operations (vROps) Management Pack for IBM DB2 User Guide describes the primary features of the Management Pack for IBM DB2, including dashboards, views, reports, alerts, and metrics that allow users to optimize the monitoring and management of IBM DB2 resources from within vRealize Operations.

2. introduction to the Management packThe Management Pack for IBM DB2 is an embedded adapter for vRealize Operations (vROps) that monitors IBM DB2 database systems remotely by creating a JBDC connection to retrieve performance data regarding DB2 database resources.

This section includes the following topics:

• How the Management Pack Collects Data• Data the Management Pack Collects

2.1 How the Management Pack Collects Data

During each data collection cycle, the Management Pack opens a JDBC connection to the specified DB2 database and queries it to retrieve resource metrics.

The collection interval for the adapter instance resource determines how often the Management Pack collects data. The default collection interval is five minutes.

2.2 Data the Management Pack Collects

The Management Pack can collect performance data, relationships (associations), and events for the following DB2 resources:

1. DB2 Adapter Instance 2. DB2 HADR (High Availability Disaster Recovery) 3. DB2 Database 4. DB2 Slow Query

2.3 Inventory Tree (Traversal Spec)

The Inventory Tree (Traversal Spec) feature within vROps allows you to easily navigate your IBM DB2 database environment. The hierarchical structure implicitly shows relationships among resource kinds and enables quick drill-downs to root-cause issues.

Figure 1: Example DB2 Traversal Spec


3. DashboardsDashboards are the primary user interface that allow users to monitor DB2 resources from within vRealize Operations.

The following dashboards are available in the Management Pack:

• DB2 Overview• DB2 on VM• DB2 IOPS• DB2 Top-N Queries

3.1 DB2 Overview

The DB2 Overview dashboard displays heat maps depicting overall health of DB2 databases and HADRs. Figure 2: DB2 Overview Dashboard


3.2 DB2 on VM

The DB2 on VM dashboard allows the user to select a DB2 database to view key performance indicators (KPIs) for the database and related Virtual Machine.

Figure 3: DB2 on VM Dashboard


3.3 DB2 IOPS

The IOPS dashboard allows the user to select a DB2 database to view IO stats for the related database, Virtual Machine, and related Datastore.

Figure 4: DB2 IOPS Dashboard

NOTE: To enable IOPs metrics for Virtual Machines, you must modify the active policy within vROps. For instructions, refer to section 5.3, Enabling VM IOPS Metrics, in the accompanying Blue Medora VMware vRealize Operations (vROps) Management Pack for IBM DB2 Installation and Configuration Guide.


3.4 DB2 Top-N Queries

The Top-N Queries dashboard allows the user to select a DB2 database to view a ranking of the Top 10 slowest queries. The dashboard also allows you to select individual queries from the heat map slowest queries selector to view performance metrics for the selected query.

Figure 5: DB2 Top-N Queries Dashboard


4. ViewsThe vROps Management Pack for IBM DB2 contains custom views, which allow the user to view statistics of metrics for DB2 resources. Views provide a “big picture” look at resources, as opposed to a more in depth view.

Table 1: IBM DB2 Views

VIEw TyPE DESCRIPTION

DB2 Application Performance List Provides a list of application performance metrics.

DB2 Buffer Pool Metrics List Provides a list of buffer pool metrics.

DB2 Health, Availability, & Alert Count List Provides a list of DB2 health, availability, and alert counts.

DB2 I/O Performance List Provides a list of I/O performance metrics.

DB2 KPIs List Provides a list of DB2 key performance metrics.

DB2 Slowest Queries List Provides a list of the slowest DB2 queries.

DB2 Tablespace Metrics List Provides a list of tablespace metrics.

To access the Management Pack views, go to Environment > DB2 and click the desired Object (resource kind). Select the Details tab, then Views. Select the desired view from the list to populate the statistics below.

For the full list of views for the Management Pack, go to Home > Content > Views.

Figure 6: Accessing DB2 Views


5. reportsThe vROps Management Pack for IBM DB2 contains the following custom reports. The report scan be exported and easily shared with key stakeholders in either .pdf or .csv formats.

Table 2: IBM DB2 Reports

REPORT DESCRIPTION

DB2 Application Provides a roll-up of DB2 application metrics.

DB2 Buffer Pool Provides a roll-up of DB2 buffer pool metrics.

DB2 Health Provides a roll-up of DB2 health metrics.

DB2 Overview Provides a roll-up of DB2 overview metrics.

DB2 Tablespace Provides a roll-up of DB2 tablespace metrics.

To access the Management Packs reports, go to Environment > DB2 and click the desired Object (resource kind). Select the Reports tab, then Report Templates.

To run the selected report, click the Run Template icon ( ).

Figure 7: Accessing DB2 Reports


6. alertsThe vROps Management Pack for IBM DB2 pulls DB2 database health indicators and displays them in vRealize Operations as alerts. The critical levels of each alert are closely mapped from IBM DB2 to vROps.

Refer to Appendix II for the full list of alerts, symptoms, and recommendations provided by this Management Pack.

7. analysis BadgesvRealize Operations Analysis Badges for IBM DB2 database systems are populated based on capacity definitions provided by this Management Pack. Refer to Appendix III for the list of capacity definitions.

Figure 8: Analysis Badge Example


8. troubleshooting the Management packKnown troubleshooting information can help you diagnose and correct common problems with the Management Pack for IBM DB2.

This section includes the following topics:

• Troubleshooting an Adapter Instance

• Testing Connection Failures

• Viewing System Log Files

8.1 Troubleshooting an Adapter Instance

Perform these general troubleshooting steps to diagnose and correct problems with an adapter instance:

• Edit the adapter instance and click Test Connection to verify the connection to vROps. Refer to section 8.2, Testing Connection Failures.

• View the collection status and collection state for the adapter instance resource on the Environment Overview page in vROps.

• Check the adapter and collector logs for errors. Refer to section 8.3, Viewing System Log Files, for details.

8.2 Testing Connection Failures

When clicking Test Connection in the Manage Solution window when adding an adapter instance, the following connection errors are possible.

8.2.1 wrong Credentials

Error: Unable to establish a valid connection to target system. Connection authorization failure occurred. Reason: User ID or Password invalid.

Action: Ensure the correct IBM DB2 system and vRealize Operations User Name and Password was entered when adding your adapter instance.

8.2.2 wrong Host

Error: Unable to establish a valid connection to target system. Required property is unknown host.Ensure the correct IBM DB2 Management IP or DNS name for you IBM DB2 System was entered.

Action: Ensure the correct hostname or IP address was entered when adding your adapter instance.

8.2.3 wrong Port

Error: Unable to establish a valid connection to target system. Connection authorization failure occurred. Error opening socket server <name> on port with message: Connection refused.

Action: Check your DB2 database system and ensure the connection port number matches the port number entered (if other than default of 50000) when adding your adapter instance.

8.2.4 wrong Database

Error: Connection authorization failure occurred. The application server rejected establishment of the connection. An attempt was made to access a database, <name>, which was either not found or does not support transactions.

Action: Ensure the database name(s) provided match the DB2 system. Multiple databases should be separated by commas in the Manage Solution window.


8.3 Viewing System Log Files

You can view IBM DB2 adapter errors in the adapter and collector log files. You can view the adapter and collector log files in the vROps user interface or in an external log viewer.

The adapter log files are in the $ALIVE_BASE/user/log/adapters/DB2Adapter/ folder. The collector log files are in the $ALIVE_BASE/user/log/ folder.

The logging level is set to ERROR by default. To troubleshoot issues, set the logging level to INFO. To view detailed messages, including micro steps, queries, and returned results, set the logging level to DEBUG.

You can set the base log level for the collector via Administrator -> Support -> Logs -> Select COLLECTOR folder -> Select Edit Properties icon -> Edit Root logger level.

NOTE: If you set the logging level to DEBUG, log files can become large very quickly. Set the logging level to DEBUG only for short periods of time.

For complete information about viewing log files and modifying log levels, refer to the vROps online help.


9. appendix i: MetricsThe Management Pack for IBM DB2 collects the following metrics by IBM DB2 Resource Kinds.

Table 3: Management Pack Metrics

RESOURCE KIND RESOURCE GROUP

RESOURCE ATTRIBUTE ATTRIBUTE TyPE

DB2 Slow Query Top N Average Execution Time double

DB2 Slow Query Top N Average User CPU Time double

DB2 Slow Query Top N Average System CPU Time double

DB2 Slow Query Top N Rows Read double

DB2 Slow Query Top N Rows Written double

DB2 Slow Query Top N Number of Executions double

DB2 Slow Query Top N Query Statement string

DB2 HADR HADR Connect Status string

DB2 HADR HADR Connect Time string

DB2 HADR HADR Heartbeat double

DB2 HADR HADR Local Host string

DB2 HADR HADR Remote Host string

DB2 HADR HADR Remote Instance string

DB2 HADR HADR Remote Service double

DB2 HADR HADR Role string

DB2 HADR HADR State string

DB2 HADR HADR Sync Mode string

DB2 HADR HADR Timeout double

DB2 Database Tablespace Extent Size double

DB2 Database Tablespace Number of Containers double

DB2 Database Tablespace Page Size double

DB2 Database Tablespace Prefetch Size double

DB2 Database Tablespace Tablespace Free Pages double

DB2 Database Tablespace Tablespace State string

DB2 Database Tablespace Tablespace Total Pages double

DB2 Database Tablespace Tablespace Type string

DB2 Database Tablespace Tablespace Usable Pages double

DB2 Database Tablespace Tablespace Used Pages double

DB2 Database Tablespace Tablespace Utilization double

DB2 Database Tablespace Number of Ranges double

DB2 Database Tablespace Bufferpool Identifier double

DB2 Database Buffer Pool Performance

Buffer Pool Hit Ratio double


Logical Data Reads double





Logical Index Reads double


Physical Data Reads double


Physical Index Reads double


Pool Asynchronous Data Reads double


Pool Asynchronous Index Reads double


Pool Asynchronous Data Writes double


Pool Asynchronous Index Writes double


Pool Asynchronous Read Time double


Pool Asynchronous Write Time double


Pool Data Writes double


Pool Index Writes double


Pool Read Time double


Pool Write Time double

DB2 Database Memory Pool Memory Pool Utilization double

DB2 Database Performance Current Database Size double

DB2 Database Performance Allocated Database Size double

DB2 Database Performance Logical Location of Database string

DB2 Database Performance Pool Asynchronous Writes double

DB2 Database Performance Buffer Pool Data Hit Ratio double

DB2 Database Performance Buffer Pool Hit Ratio double

DB2 Database Performance Buffer Pool Index Hit Ratio double

DB2 Database Performance Logical Data Reads double

DB2 Database Performance Logical Index Reads double

DB2 Database Performance Physical Data Reads double

DB2 Database Performance Physical Index Reads double

DB2 Database Performance Percentage of Applications Waiting on Locks

double

DB2 Database Performance Number of Applications Waiting on Locks

double

DB2 Database Performance Average Lock Wait Time double

DB2 Database Performance Commit SQL Statements double




DB2 Database Performance Connection Time string

DB2 Database Performance Physical Disk Location of Database string

DB2 Database Performance Number of Deadlocks double

DB2 Database Performance Dynamic SQL Statements double

DB2 Database Performance Failed SQL Statements double

DB2 Database Performance Number of Exclusive Lock Escalations

double

DB2 Database Performance Number of Internal Rollbacks double

DB2 Database Performance Number of Internal Deadlock Rollbacks

double

DB2 Database Performance Last Reset double

DB2 Database Performance Number of Lock Escalations double

DB2 Database Performance Total Locklist Memory in Use double

DB2 Database Performance Number of Lock Timeouts double

DB2 Database Performance Total Lock Wait Time double

DB2 Database Performance Number of Locks Held double

DB2 Database Performance Number of Lock Waits double

DB2 Database Performance Pool Asynchronous Data Reads double

DB2 Database Performance Pool Asynchronous Data Writes double

DB2 Database Performance Pool Asynchronous Index Reads double

DB2 Database Performance Pool Asynchronous Index Writes double

DB2 Database Performance Pool Asynchronous Read Time double

DB2 Database Performance Pool Asynchronous Write Time double

DB2 Database Performance Pool Synchronous Data Reads double

DB2 Database Performance Pool Synchronous Data Writes double

DB2 Database Performance Pool Synchronous Index Reads double

DB2 Database Performance Pool Synchronous Index Writes double

DB2 Database Performance Pool Data Writes double

DB2 Database Performance Pool Index Writes double

DB2 Database Performance Pool Data Logical Reads double

DB2 Database Performance Pool Data Physical Reads double

DB2 Database Performance Pool Index Logical Reads double

DB2 Database Performance Pool Index Physical Reads double

DB2 Database Performance Pool Read Time double

DB2 Database Performance Pool Write Time double

DB2 Database Performance Rollback SQL Statements double

DB2 Database Performance Static SQL Statements double

DB2 Database Performance Number of Current Connections double

DB2 Database Performance Deadlock Rate double

DB2 Database Performance Commit SQL Statements Rate double




DB2 Database Performance Dynamic SQL Statements Rate double

DB2 Database Performance Exclusive Lock Escalation Rate double

DB2 Database Performance Failed SQL Statements Rate double

DB2 Database Performance Internal Deadlock Rollbacks Rate double

DB2 Database Performance Lock Escalation Rate double

DB2 Database Performance Lock Timeouts Rate double

DB2 Database Performance Rollback SQL Statements Rate double

DB2 Database Performance Static SQL Statements Rate double

DB2 Database Performance Average Data Write Rate double

DB2 Database Performance Average Index Write Rate double

DB2 Database Performance Average Page Read Rate double

DB2 Database Performance Average Page Write Rate double

DB2 Database Performance Logical Data Read Rate double

DB2 Database Performance Logical Index Read Rate double

DB2 Database Performance Physical Data Read Rate double

DB2 Database Performance Physical Index Read Rate double

DB2 Database Performance Synchronous Data Read Rate double

DB2 Database Performance Synchronous Data Write Rate double

DB2 Database Performance Synchronous Index Read Rate double

DB2 Database Performance Synchronous Index Write Rate double

DB2 Database Log Log Space Utilization double

DB2 Database Log Total Log Used double

DB2 Database Log Log Reads double

DB2 Database Log Log Writes double

DB2 Database Application Connection

Active Applications double


Maximum Active Applications double


Applications Connected double


Total Connections double


Active Local Connections double


Active Remote Connections double


Local Connections double


Remote Connections double

DB2 Database Backup Time of Last Backup string

DB2 Database Backup Days Since Last Backup double




DB2 Database Cache Performance

Catalogue Cache Inserts double


Catalogue Cache Lookups double


Catalogue Cache Overflows double


Package Cache Inserts double


Package Cache Lookups double


Package Cache Max Used double


Package Cache Overflows double


Catalog Cache Hit Ratio double


Catalog Cache Heapfull double


Package Cache Hit Ratio double

DB2 Database IO Agents Buffer Pool Victim Page Cleaner Invokes

double

DB2 Database IO Agents Buffer Pool Threshold Page Cleaner Invokes

double

DB2 Database Memory Manager Total Locklist Memory in Use double

DB2 Database Non Buffered IO Performance

Average Direct Write Rate double


Average Direct Read Rate double


Direct Read Requests double


Direct Read Time double


Direct Reads double


Direct Write Requests double


Direct Write Time double


Direct Writes double


Average Data Read Rate double

DB2 Database Sort Heap Active Sorts double

DB2 Database Sort Heap Post Threshold Hash Joins double

DB2 Database Sort Heap Post Threshold Sorts double




DB2 Database Sort Heap Sort Heap Pages Allocated double

DB2 Database Sort Heap Sort Overflows double

DB2 Database Sort Heap Total Hash Joins double

DB2 Database Sort Heap Total Hash Loops double

DB2 Database Sort Heap Total Hash Join Overflows double

DB2 Database Sort Heap Total Hash Join Small Overflow double

DB2 Database Sort Heap Total Sort Time double

DB2 Database Sort Heap Total Sorts double

DB2 Database Sort Heap Small Overflow Hash Joins to Total Hash Joins Ratio

double

DB2 Database Sort Heap Average Post Threshold Joins Rate double

DB2 Database Sort Heap Average Post Threshold Sorts Rate double

DB2 Database Sort Heap Piped Sorts Accepted double

DB2 Database Sort Heap Piped Sorts Requested double

DB2 Database Sort Heap Piped Sorts Rejected double

DB2 Database Sort Heap Average Active Sorts Rate double

DB2 Database Sort Heap Average Hash Join Overflow Rate double

DB2 Database Sort Heap Average Hash Join Rate double

DB2 Database Sort Heap Average Hash Join Small Overflow Rate

double

DB2 Database Sort Heap Average Hash Join Small Overflow Ratio

double

DB2 Database Sort Heap Average Hash Loops Rate double

DB2 Database Sort Heap Average Piped Sorts Rejected Rate double

DB2 Database Sort Heap Average Sorts Rate double

DB2 Database Summary Status string

DB2 Database Agents Connection

Agent Created due to Empty Pool double


Agent Waiting Top double


Agents Registered double


Coordination Agents Top double


Idle Agents double


Pool Agents double


Agents Assignment Rate double


Agent Creation Rate double


Agent Creation to Assignment Ratio double




DB2 Database Instance Startup Time string

DB2 Database Instance Status string

DB2 Database Instance Registered Agents double

DB2 Database Instance Allocated Sort Heap Memory double

DB2 Database Instance Committed Private Memory double

DB2 Database Instance Sort Heap Threshold double

DB2 Database Instance Sort Heap Utilization double


10. appendix ii: alertsThe vROps Management Pack for IBM DB2 creates alerts based on various symptoms that it detects in the environment. See the table below for details regarding each alert.

Table 4: Management Pack Alerts

NAME DESCRIPTION SyMPTOM RECOMMENDATION

Database Operational State

The state of the database can restrict activity or tasks that can be performed. The state can be one of the following: ACTIVE, QUIESCE PENDING, QUIESCED, or ROLLFORWARD. A change from Active to another state may generate an Attention alert.

Database Operational State

Refer to the DB2 Information Center for information on these states.

Shared Sort Memory Utilization

A sample event has been detected

Shared Sort Memory Utilization

Sorting is considered healthy if there is sufficient heap space in which to perform sorting and sorts do not overflow unnecessarily. This indicator tracks the utilization of the shared sort memory. The SHEAPTHRES_SHR database configuration parameter is a soft limit. If the allocation is close to the limit, an alert may be generated. The indicator is calculated using the formula: (db.sort_shrheap_allocated / SHEAPTHRES_SHR) * 100. The Maximum Shared Sort Memory Used snapshot monitor element maintains a shared sort memory high-water mark for the database. The value of this indicator, shown in the Additional Information, indicates the maximum amount of shared sort memory that has been in use at any one point in time since the database has been active. This value can be used to help determine an appropriate value for the shared sort memory threshold. This health indicator's threshold checking is not enabled by default in new installations where self tuning memory is expected to be used.



Percentage of Sorts That Overflowed


Percentage of Sorts That Overflowed

Sorting is considered healthy if there is sufficient heap space in which to perform sorting and sorts do not overflow unnecessarily. Sorts that overflow to disk can cause significant performance degradation. Some level of sort overflows however, may be unavoidable in such cases where the size of the sort exceeds physical memory or the maximum available memory for the database. If a high percentage of sorts spill, an alert may be generated. The indicator is calculated using the formula: (db.sort_overflows / db.total_sorts)*100. The system monitor data element db.sort_overflows is the total number of sorts that ran out of sort heap and may have required disk space for temporary storage. The data element db.total_sorts is the total number of sorts that have been executed. This health indicator's threshold checking is not enabled by default in new installations where self tuning memory is expected to be used.

Long Term Shared Sort Memory Utilization


Long Term Shared Sort Memory Utilization

Sorting is considered healthy if there is sufficient heap space in which to perform sorting and sorts do not overflow unnecessarily. This indicator tracks an over-configured shared sort heap, whose memory could be better used somewhere else in DB2. An alert may be generated when the percentage usage is low. The indicator is calculated using the formula: (db.max_shr_sort_mem / SHEAPTHRES_SHR)*100. This health indicator's threshold checking is not enabled by default in new installations where self tuning memory is expected to be used.

Log Utilization A sample event has been detected

Log Utilization

This indicator tracks the total amount of active log space used in bytes in the database. Log utilization is measured as the percentage of space consumed, where a high percentage may generate an alert. The indicator is calculated using the formula: (db.total_log_used / (db.total_log_used + db.total_log_available))*100. The values for the log-related database configuration parameters, shown in the additional information, display the current allocations for logs. The additional information also includes the application id for the application which has the oldest active transaction. This application can be forced to free up log space.



Log Filesystem Utilization


Log Filesystem Utilization

Log Filesystem Utilization tracks the fullness of the filesystem on which the transaction logs reside. DB2 may not be able to create a new log file if there is no room on the filesystem. Log utilization is measured as the percentage of space consumed. If the amount of free space in the filesystem is minimal (i.e. high percentage for utilization), an alert may be generated. The indicator is calculated using the formula: (fs.log_fs_used / fs.log_fs_total)*100 where fs is the filesystem on which the log resides. The values for the log-related database configuration parameters, shown in the additional information, display the current allocations for logs. The additional details also shows if log archiving is enabled. If Block on Log Disk Full, shown in the additional details, is set to yes and utilization is at 100%, you should resolve any alerts as soon as possible to limit the impact to applications which cannot commit transactions until the log file is successfully created.

Deadlock Rate A sample event has been detected

Deadlock Rate

Deadlock rate tracks the rate at which deadlocks are occurring in the database and the degree to which applications are experiencing contention problems. Deadlocks may be caused by the following situations: o Lock escalations are occurring for the database o An application may be locking tables explicitly when system- generated row locks may be sufficient o An application may be using an inappropriate isolation level when binding o Catalog tables are locked for repeatable read o Applications are getting the same locks in different orders, resulting in deadlock. The indicator is calculated using the formula: (db.deadlocks<t> - db.deadlocks<t-1>) where 't' is the current snapshot and 't-1' is the last snapshot "5" "minutes" ago. A high rate of deadlocks results in a greater degree of contention which may generate an alert.



Lock List Utilization


Lock List Utilization

This indicator tracks the amount of lock list memory that is being used. There is one lock list per database and it contains the locks held by all applications concurrently connected to the database. There is a set limit on lock list memory. Once the limit is reached, performance degrades because of the following situations: o Lock escalation converts row locks to table locks, thereby reducing concurrency on shared objects in the database. o More deadlocks between applications can occur since applications are waiting for a limited number of table locks. As a result, transactions are rolled back. An error is returned to the application when the maximum number of lock requests has reached the limit set for the database. The indicator is calculated using the formula: (db.lock_list_in_use / (LOCKLIST * 4096)) * 100. Utilization is measured as a percentage of memory consumed, where a high percentage represents an unhealthy condition. This health indicator's threshold checking is not enabled by default in new installations where the self tuning memory feature is expected to be used.

Lock Escalation Rate


Lock Escalation Rate

This indicator tracks the rate at which locks have been escalated from row locks to a table lock thereby impacting transaction concurrency. A lock is escalated when the total number of locks held by an application reaches the maximum amount of lock list space available to the application, or the lock list space consumed by all applications is approaching the total lock list space. The amount of lock list space available is determined by the MAXLOCKS and LOCKLIST database configuration parameters. When an application reaches the maximum number of locks allowed and there are no more locks to escalate, the application uses the space in the lock list allocated for other applications. There is one lock list per database and it contains the locks held by all applications concurrently connected to the database. When the entire lock list is full an error occurs. The indicator is calculated using the formula: (db.lock_escals<t> - db.lock_escals<t-1>) where 't' is the current snapshot and 't-1' is the last snapshot "5" "minutes" ago. A high rate of deadlocks results in a greater degree of contention which may generate an alert. This health indicator's threshold checking is not enabled by default in new installations where the self tuning memory feature is expected to be used.



Percentage of Applications Waiting on Locks


Percentage of Applications Waiting on Locks

This indicator measures the percentage of all currently executing applications that are waiting on locks. A high percentage can indicate that applications are experiencing concurrency problems which can negatively affect performance. The indicator is calculated using the formula: (db.locks_waiting / db.appls_cur_cons) *100). This health indicator's threshold checking is not enabled by default in new installations where the self tuning memory feature is expected to be used.

Package Cache Hit Ratio


Package Cache Hit Ratio

The hit ratio is a percentage indicating how well the package cache is helping to avoid reloading packages and sections for static SQL from the system catalogs as well as helping to avoid recompiling dynamic SQL statements. A high ratio indicates it is successful in avoiding these activities. The indicator is calculated using the formula: (1-(db.pkg_cache_inserts/db.pkg_cache_lookups))*100. This health indicator's threshold checking is not enabled by default in new installations where the self tuning memory feature is expected to be used.

Catalog Cache Hit Ratio


Catalog Cache Hit Ratio

The hit ratio is a percentage indicating how well the catalog cache is helping to avoid actual accesses to the catalog on disk. A high ratio indicates it is successful in avoiding actual disk I/O accesses. The indicator is calculated using the formula: (1-(db.cat_cache_inserts/db.cat_cache_lookups))*100.

Shared Workspace Hit Ratio


Shared Workspace Hit Ratio

he hit ratio is a percentage indicating how well the shared SQL workspace is helping to avoid having to initialize sections for SQL statements that are about to be executed. A high ratio indicates it is successful in avoiding this action. The indicator is calculated using the formula: (1-(db.shr_workspace_section_inserts/db.shr_workspace_section_lookups))*100.

Database Heap Utilization


Database Heap Utilization

This indicator tracks the consumption of the monitor heap memory, based on the memory pool with the ID SQLM_HEAP_DATABASE. The utilization is calculated using the formula (db.pool_cur_size / db.pool_max_size) * 100 for the Memory Pool Identifier SQLM_HEAP_DATABASE. Once this percentage reaches the maximum, 100%, queries and operations may fail because there is no heap available.



Reorganization Required


Reorganiza-tion Required

This health indicator tracks the need to reorganize tables or indexes within a database. Tables or all indexes defined on a table require reorganization to eliminate fragmented data. The reorganization is accomplished by compacting the information and reconstructing the rows or index data. This may result in a performance improvement and space in the table or indexes being freed. The tables considered by this health indicator can be limited using an SQL query. The scope in the additional information displays the subselect clause on system tables for this query. Refer to the DB2 Information Center for how to update this query. An attention alert might be generated to indicate that reorganization is required. Reorganization can be automated by setting the AUTO_REORG database configuration parameter to ON. If automatic reorganization is enabled, the attention alert indicates that one or more automatic reorganizations could not complete successfully. Refer to the collection details of this health indicator for the list of objects that need attention.

HADR Operational status


HADR Operational status

This health indicator tracks the DB2 High Availability Disaster Recovery (HADR) operational state of the database. The state between primary and standby servers can be one of the following: CONNECTED, CONGESTED or DISCONNECTED. A change from CONNECTED to another state might generate an Attention alert. Refer to the DB2 Information Center for information on these states.

HADR Log Delay A sample event has been detected

HADR Log Delay

This health indicator tracks the current average delay (in minutes) between the data changes on the primary database and the replication of those changes on the standby database. The large delay value represents a possibility of a data loss in case of failover when a failure on primary occurs. Moreover, the large delay value may also mean longer downtime when takeover is required, since the standby is not yet a failover candidate, as the current primary is ahead of the standby.



Database Backup Required


Database Backup Required

This health indicator tracks the need for a backup on the database. Backups should be taken regularly as part of a recovery strategy to protect your data against the possibility of loss in the event of a hardware or software failure. This health indicator determines when a database backup is required based on the time elapsed and amount of data changed since the last backup. Refer to the DB2 Information Center for information about how to update these settings. An attention alert might be generated to indicate that a database backup is required. Database backups can be automated by setting the AUTO_DB_BACKUP database configuration parameter to ON. If automatic database backups are enabled

Nickname Status


Nickname Status

This health indicator checks all of the nicknames defined in a federated database to determine if there are any invalid nicknames. A nickname may be invalid if the data source object was dropped or changed or if the user mapping is incorrect. An attention alert might be generated if any nicknames defined in the federated database are invalid. Refer to the collection details of this health indicator for the list of objects that need attention.

Data Source Server Status


Data Source Server Status

This health indicator checks all of the data source servers defined in a federated database to determine if any are unavailable. A data source server may be unavailable if the data source server was stopped, no longer exists, or was incorrectly configured. An attention alert might be generated if any data source servers defined in the federated database are invalid. Refer to the collection details of this health indicator for the list of objects that need attention.

Statistics Collection Required


Statistics Collection Required

This health indicator tracks the need to collect statistics for tables and their indexes within a database. Tables and all indexes defined on a table require statistics to improve query execution time. The tables considered by this health indicator can be limited using an SQL query. The scope in the additional information displays the subselect clause on system tables for this query. Refer to the DB2 Information Center on how to update this query. An attention alert may be generated to indicate that statistics collection is required. Statistics can be automatically collected by setting the AUTO_RUNSTATS database configuration parameter to ON. If automatic statistics collection is enabled, the attention alert indicates that one or more automatic statistics collection actions could not complete successfully. Refer to the collection details of this health indicator for the list of objects that need attention.



Database Automatic Storage Utilization


Database Automatic Storage Utilization

This health indicator tracks the consumption of storage for the defined database storage paths. When automatic storage table spaces are created, containers will be allocated automatically for these table spaces on the database storage paths. If there is no more space on any of the filesystems on which the database storage paths are defined, automatic storage table spaces will be unable to increase in size and may become full. This indicator is calculated using the formula: (db.auto_storage_used / db.auto_storage_total) * 100 where db.auto_storage_used and db.auto_storage_total are the sum of used and total space respectively across all physical filesystems identified in the list of database storage paths. Database automatic storage path utilization is measured as a percentage of the space consumed on the database storage path filesystems, where a high percentage indicates less than optimal function for this indicator. The calculation of time remaining to fullness in the additional information is a prediction of how much time is remaining until all free space is consumed.

Table Space Operational State


Table Space Operational State

The state of a table space can restrict activity or tasks that can be performed. A change from normal to another state might generate an Attention alert. For a complete list of possible table space states, refer to the DB2 Information Center.

Table Space Utilization


Table Space Utilization

This health indicator tracks the consumption of storage for each DMS table space. The DMS table space is considered full when all containers are full. If automatic resize is enabled on the table space this alert condition may correct itself when the table space resizes. The indicator is calculated using the formula: (ts.used / ts.useable) * 100 where ts.used and ts.useable are the system monitor data elements Used Pages in Table Space and Useable Pages in Table Space, respectively. Table space utilization is measured as the percentage of space consumed, where a high percentage indicates less than optimal function for this indicator. The short term and long term growth rates, included in the additional information for this indicator, can be used to determine if current rate of growth is a short term aberration or consistent with longer term growth. The calculation of time remaining to fullness in the additional information is a prediction of how much time is remaining until all free space is consumed.



Table Space Automatic Resize Status


Table Space Automatic Resize Status

This health indicator identifies whether or not tablespace resize operations are succeeding for DMS tablespaces which have automatic resize enabled. When a DMS tablespace with automatic resize enabled fails to increase in size it is effectively full. This condition may be due to lack of free space on the filesystems on which the tablespace containers are defined, or a result of the tablespace automatic resize settings. For example, the defined maximum size may have been reached, or the increase amount may be set too high to be accommodated by the remaining free space. Refer to the additional information for details about the tablespace and the automatic resize settings.

Automatic Resize Table Space Utilization


Automatic Resize Table Space Utilization

This health indicator tracks the consumption of table space storage for each automatic resize DMS table space on which a maximum size has been defined. The DMS table space is considered full when the maximum size has been reached. The indicator is calculated using the formula: ((ts.used * ts.page_size) / ts.max_size) * 100 where ts.used, ts.page_size and ts.max_size are the system monitor data elements Used Pages in Table Space, Table Space Page Size and Maximum Table Space Size, respectively. Automatic resize DMS Table Space utilization is measured as a percentage of the maximum table space storage consumed. A high percentage indicates the table space is approaching fullness. The short term and long term growth rates, included in the additional information for this indicator, can be used to determine if current rate of growth is a shot term aberration or consistent with long term growth. The calculation of time remaining to fullness in the additional information is a prediction of how much time there is remaining until the maximum size has been reached.


11. Appendix III: Capacity DefinitionsThe Management Pack for IBM DB2 uses the following capacity definitions, which help determine the value of Analysis Badges for an IBM DB2 System within vRealize Operations (refer to Section 7).

Table 5: Capacity Definitions

CONTAINER USE IN wORKLOAD?

DB2 Database

vRealize Computed Database Capacity yes

vRealize Computed Application Capacity yes

Copyright © 2015 Blue Medora Inc. All rights reserved. U.S. and international copyright and intellectual property laws protect this product. Blue Medora is a registered trademark or trademark of Blue Medora in the United States and/or other jurisdictions.

The IBM name (including IBM DB2) and logo are trademarks or registered trademarks of International Business Machines, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.

Blue Medora

3225 N Evergreen Dr. NE Suite 103

Grand Rapids, MI 49525

www.bluemedora.com

You can find the most up-to-date technical documentation on the Blue Medora support site at: http://support.bluemedora.com.

The Blue Medora website also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected].

ibm db2 - blue medora · 3 blue medora vmware vrealize operations management pack for ibm db2 user...

Documents