MAINTAINING THE DOMINO AND DB2 ENVIRONMENT


Generating a database monitor snapshot
A snapshot is a point-in-time view of the monitoring elements being analyzed, some of which are cumulative. Cumulative elements contain information relative to the start of monitoring and ending at the time of the snapshot. Other (noncumulative) elements reflect the elements of a gauge that varies according to the activity on your system.

IBM® DB2 Universal Database™ Enterprise Server Edition contains several default monitoring switches. Each of the monitoring switches gathers data for a specific configuration parameter. DB2 contains these default monitoring switches:
Configuration parameterDefault database monitor switch
Buffer PoolDFT_MON_BUFPOOL = ON
LockDFT_MON_LOCK = OFF
SortDFT_MON_SORT = OFF
StatementDFT_MON_STMT = OFF
TableDFT_MON_TABLE = OFF
Unit of workDFT_MON_UOW = OFF
You can generate a list of these switches by entering the following command from the DB2 Command Line Processor (CLP):


Enable monitors using the same process you will later use to obtain the snapshot. On Microsoft® Windows® platforms, use a cmd.exe session, while on IBM® AIX®, Linux®, or UNIX®, use a shell.

By default, the timestamp parameter is on, but it is best to explicitly set timestamp to on because it is possible to turn timestamp off. This is the timestamp of the log being processed.

You can take a snapshot of the data that is gathered during the monitoring session for any configuration parameter whose switch is set to On. To generate a snapshot for diagnostic purposes, the DB2 monitors must be turned on.

To obtain a database monitor snapshot, enter this command from the CLP:


Dynamic SQL Snapshot Result

When you generate an SQL snapshot, the snapshot output displays on the computer monitor. It is not saved to a log file. To save the snapshot to a file so that you can review the information at a later time, use this command:


To obtain a snapshot and to use I/O redirection to save the output to a file, issue the following commands during the same process:

Note The commands are also explained below.


Explanation of commands

The symbol > (single greater than) writes the output of the command to a file. Text in the file is overwritten. The symbol >> (double greater than) appends the output of the command to a file. It does not overwrite existing text, it just appends new text to the end of the file.

This sequence of commands produces the following results:


The following is a sample of the output generated for one statement:
OutputExplanation
Number of executions = 20Times the query has run
Number of compilations = 1Times the SQL compiler and optimizer have processed the statement
Worst preparation time (ms) = 3Worst case, compiler and optimizer processing
Best preparation time (ms) = 3Best case, compiler and optimizer processing)
Internal rows deleted = 0Temp
Internal rows inserted = 0Temp
Rows read = 0Including temp
Internal rows updated = 0Temp
Rows written = 0Including temp
Statement sorts = 20Times DB2 sorted data during the execution of this statement. Usually = Number of executions
Statement sort overflows = 0Sort space spilling to disk (not good to even sort, but if this happens, it's really not good)
Total sort time = 0Sec.ms -- shows the true cost of sorting across all executions. In this case, sorts are inexpensive.
Buffer pool data logical reads = 0Times a page containing data rows was accessed without reading data from disk
Buffer pool data physical reads = 0 Times a page containing data rows was accessed and data was read from disk
Buffer pool temporary data logical reads = 0Times a page containing temporary data rows (for example, sorted data) was accessed without reading data from disk
Buffer pool temporary data physical reads = 0Times a page containing temporary data rows (for example, sorted data) was accessed and data was read from disk
Buffer pool index logical reads = 1300Times a page containing index data was accessed without reading data from disk
Buffer pool index physical reads = 0 Times a page containing index data was accessed and data was read from disk
Buffer pool temporary index logical reads = 0Times a page containing temporary index data (for example, sorted data) was accessed without reading data from disk
Buffer pool temporary index physical reads = 0Times a page containing temporary index data (for example, sorted data) was accessed and data was read from disk
Total execution time (sec.ms) = 0.104943 (across all executions)
Total user cpu time (sec.ms) = 0.100145 (")
Total system cpu time (sec.ms) = 0.010015 (")
Statement text = SELECT nsfid, viewid, collation, branch, hassubcategory, refunid, COUNT(*) FROM GRP3.ND002115F385256FF0 WHERE refunid IN ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) AND nsfid=? AND viewid = ? AND collation = ? AND branch = ? AND hassubcategory = ? GROUP BY viewid, nsfid, collation, branch, hassubcategory, refunid ORDER BY viewid, nsfid, collation, branch, hassubcategory, refunid (the actual statement as DB2 saw it)

Using a snapshot to detect negative locking behavior

Use the data that is gathered in the snapshot to detect negative locking behavior. To do so, locate the section titled "Database Lock Snapshot." A lock entry in your snapshot will look similar to this example:
Lock Name =0x0D000700000000000000000054
Lock Attributes =0x00000000
Release Flags =0x00000001
Lock Count =1.00
Hold Count =1.00
Lock Object Name =7.00
Object Type =Table
Tablespace Name =GRP8
Table Schema =GRP8
Table Name =NSFNOTE
Mode = X
The data in this snapshot indicates that the locklist setting is too small. DB2 consolidated multiple row locks into one exclusive table lock. This has severe consequences for system performance.

If DB2 monitor snapshots show numerous row locks escalated to table locks, consider increasing the size of the locklist parameter.

Related topics