|
Problem IC64147
|
Status: Closed |
REDESIGN LOCKING MECHANISM FOR DB2 RECOVERY HISTORY FILE ACCESS |
| product: |
DB2 FOR LUW / DB2FORLUW / 910 - 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 AFFETCED:
All
PROBLEM DESCRIPTION:
See ERROR DESCRIPTION
PROBLEM SUMMARY:
See ERROR DESCRIPTION |
| 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.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
|
| Solution |
Problem was first fixed in Version 9.1 Fix Pack 9. |
| Workaround |
See LOCAL FIX. |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC65678 IC65769
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 27.10.2009
16.04.2010
16.04.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.1.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.9
|
 |
