How Sysview/DB2(IDB2) reports on lock contention?

book

Article ID: 106768

calendar_today

Updated On:

Products

CA Bind Analyzer for DB2 for z/OS CA SQL-Ease for DB2 for z/OS CA Sysview Performance Management Option for DB2 for z/OS CA Plan Analyzer for DB2 for z/OS CA Subsystem Analyzer for DB2 for z/OS

Issue/Introduction

How does Sysview/DB2(IDB2) gathers the information used to report on lock contention?
Sysview/DB2(IDB2) creates IFCID 1017 records internally, and that IFCID 1017 is not an IBM IFCID. How does Sysview gather the 1017 record information? Control block sampling? Or via the IBM DB2 IFI interface? How much overhead is involved when Sysview gathers the IFCID 1017 information?

Environment

Release:
Component: CIDB

Resolution

The IFCID 1017, is a "pseudo-IFCID" that Sysview/DB2(IDB2) creates based on data it finds when scanning the IRLM control blocks. These control blocks are found in the IRLM address space. The control blocks are undocumented and don't have proper names, so there is no way to really describe them much, other than to say that every lock holder and waiter will exist on a chain in the IRLM address space, and that is the source that is used to populate the IRLMCONT request. It has been CA expectation that IBM would eventually create their own IFI record that would provide the same info via an IFI READS call, but that still hasn't happened.
For the overhead, there is virtually no overhead to this process. The IRLMCONT request only executes code when somebody goes to the screen and hits (enter).
If an modified IRLMCONT  version that executes every "n" seconds, it will execute regularly, of course. The overhead is still very low, but there is one caveat that should be considered: the Sysview/DB2 data collector does not execute at as high a dispatching priority as IRLM, and there is always a chance that IRLM control block chains may be altered WHILE Sysview/DB2  is looking at them. This generally results in an program check. This situation is expected, and recover from the ABEND and retry the scan from the beginning. The overhead of the program check/recovery/retry is more significant, but still pretty low (as long as it isn't happening too frequently). So some care should be taken that the modified request isn't executed more often than necessary.