|
Problem IC65678
|
Status: Closed |
REDESIGN LOCKING MECHANISM FOR DB2 RECOVERY HISTORY FILE ACCESS |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
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. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All *
****************************************************************
* PROBLEM DESCRIPTION: *
* 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. *
****************************************************************
* RECOMMENDATION: *
* First Fixed in DB2 V9.5 FixPak 7 *
**************************************************************** |
| Local Fix: |
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. |
| available fix packs: |
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Redesign. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 20.01.2010
10.05.2011
10.05.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.
|
| Problem solved according to the fixlist(s) of the following version(s) |
