What is Snapshot History and how can it be used?
The OMEGAMON for Db2 Performance Expert Client (short PE Client) is a standalone Java GUI and it allows to show the saved snapshot history data for System Statistics, System Parameters and Current Thread Activity. The interval when these snapshots are collected by the OMEGAMON Db2 collector address space can be customized (down to 1s) using Configuration Manager or PARMGEN parameters.
The PE Client user can switch to the “History mode”, for example on a Thread Summary screen, to navigate back through the collected current “Thread summary” history data. This proves to be very useful if problems with deadlock or timeouts need to be assessed “after the fact”.
The following screen shot shows a PE Client Thread Summary display in “History” mode and highlights the History slider bar:
Using Thread Filters in Snapshot History
OMEGAMON for Db2 provides collection filtering capabilities for Thread Snapshot History to manage the contents of the History data set more efficiently. These filters are applied when requesting Thread Snapshot History data from Db2 z/OS.
Up to six so called Thread history qualifications, based on four filters, are supported. The filters are supported for Connection ID, Correlation ID, Plan and Primary AuthID and are to be configured with Configuration Manager or PARMGEN as part of the monitoring profile definition:
KD2_PFnn_SH_D2SQCONx – Connection ID Thread filter
KD2_PFnn_SH_D2SQCORx - Correlation ID Thread filter
KD2_PFnn_SH_D2SQPLAx – Plan name Thread filter
KD2_PFnn_SH_D2SQPRIx – Primary AUTHID Thread filter
Thread data is collected once for each matching history qualification. Be aware that this can have an impact on the space requirements. If a thread matches more than one history qualification, the thread data is collected as many times as the qualification matches, thus potentially displaying duplicates when browsing the history data in the PE Client.
Thread Snapshot History “include” examples
Let’s have a look at the following example configuration parameters:
This example tells the Snapshot History function to collect only Threads having plan name – “MYPLAN” – all other qualification filters are using wildcards (“*”), that is they match “any value”.
Example 2 uses two qualifications: The first qualification is equivalent to the on in Example 1 (use plan MYPLAN). The second qualification is using “TESTPLAN” as the plan name, and the “USER1” as the Primary Auth ID, while other filters show only a wildchar.
In this case for Db2 z/OS collections are distinct (no duplicate threads).
The new Thread filtering “exclude” capability
With UI92482 PTF the new exclude filtering capability was introduced. The exclude option can be used on first qualification of filters only.
Conceptually we are inverting the meaning of the existing qualification filters by adding a suffix “/EX” to any of the four filters supported.
In Example 3 the user wants to exclude all threads with plan name "TESTPLAN" from the history collection. These plans might be just “noise” and not worth taking up space in the history data set.
KD2_PF01_SH_D2SQPLA1 " /EX"
Example 4 excludes all threads which have an empty plan name and all threads that have “MYID” as Primary AuthID.
The empty plan filter (" /EX") can be used to save a lot of space in the history data set, especially for those environments that deal with a large number of idle distributed threads waiting to be re-utilized.
If you are a Performance Expert Client user and are using the Snapshot History feature, consider using the Thread qualifications in general and the new exclude filter capabilities in particular to make the most efficient use of your Snapshot History data set.
#ZAIOPS #OMEGAMON #IBMZ