A fix is available
APAR status
Closed as program error.
Error description
Severe page latch contention in datasharing caused by delays in processing internal timer requests. Those delays are in turn caused by delays in storage block processing for timer requests resulting from a build up of castout control blocks in the storage pool. Keywords: ABTMQLTH ABPSP2 CRB DB2STGLK/K
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: DB2 data sharing users. * **************************************************************** * PROBLEM DESCRIPTION: Storage growth and possible performance * * degradation due to buildup of long * * chains of castout request blocks. * **************************************************************** * RECOMMENDATION: * **************************************************************** If a castout engine is processing a request which takes a long time to complete (such as for GBP checkpoint processing), it is possible for a very large number of new castout requests to be queued up for the same object. Each request is represented by a castout request block (CRB), so a large number of CRBs may end up being allocated. This can cause an increase in the size of the storage pool they're allocated in (the BB1RMID pool, also known as the ABPSP2 pool). Additionally, the lengthy storage block chains can result in a performance degradation when allocating and freeing storage in that pool. This performance degradation may also manifest itself as an increase in page latch wait time since page latch waits require allocating and freeing a block in that same pool.
Problem conclusion
The castout logic has been modified to no longer queue up a CRB for a new castout request when an engine is already actively processing a castout request which renders the new one redundant (e.g. if DB2 is already casting out the entire pageset, it makes no sense to queue up a CRB for a CLASST request).
Temporary fix
Comments
APAR Information
APAR number
PM04401
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-01-04
Closed date
2010-01-22
Last modified date
2011-02-15
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK53768 UK53769
Modules/Macros
DSNB1PCD DSNB1PCO DSNB5PCO DSNDPB
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
15 February 2011