DB2 - Problem description
Problem IC65769 | Status: Closed |
REDESIGN LOCKING MECHANISM FOR DB2 RECOVERY HISTORY FILE ACCESS | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - 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 version 9 * **************************************************************** * PROBLEM DESCRIPTION: * * see error description above * **************************************************************** * RECOMMENDATION: * * Upgrade to Version 9.7 Fix Pack 2 * **************************************************************** | |
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.7 Fix Pack 2 for Linux, UNIX, and Windows | |
Solution | |
Problem was first fixed in Version 9.7 Fix Pack 2 | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 25.01.2010 14.12.2010 14.12.2010 |
Problem solved at the following versions (IBM BugInfos) | |
9.7.FP2 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.2 |