How Sysview/DB2(IDB2) reports on lock contention?
Article ID: 106768
Updated On:
Products
Bind Analyzer for DB2 for z/OS
SQL-Ease for DB2 for z/OS
SYSVIEW Performance Management Option for DB2 for z/OS
Plan Analyzer for DB2 for z/OS
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?
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
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.
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.
Feedback
Yes
No
Powered by
