DB2 FOR LUW / DB2FORLUW / 910 - DB2

Concurrent access to the DB2 recovery history file is currently 
accomplished by using operating system semaphore primitives - 
semop() calls. 
Two different potential problem areas were identified when 
accessing/locking the history file in parallel via it's 
several API's: 
 
1) Frequent semop() calls may cause performance issues (high 
   CPU usage) especially if the history file is very large. 
 
2) There is a small timing window where DB2 may hang when 
   a process is killed while initializing the semaphore. 
 
The fix for this APAR will ensure that the above problems are 
avoided by redesigning the internal locking mechanism used by 
DB2.

USERS AFFETCED: 
All 
 
PROBLEM DESCRIPTION: 
See ERROR DESCRIPTION 
 
PROBLEM SUMMARY: 
See ERROR DESCRIPTION

Avoid frequent parallel access to the recovery history file. 
 
and/or 
 
try to prune the recovery history file on regular intervals to 
keep it's size small.

DB2 Version 9.1 Fix Pack 9  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 10  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 11  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 12  for Linux, UNIX and Windows
 

Problem was first fixed in Version 9.1 Fix Pack 9.

See LOCAL FIX.

Vorgänger  : APAR is sysrouted TO one or more of the following: IC65678 IC65769 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

27.10.2009
16.04.2010
16.04.2010

9.1.FP9