|
Problem IC65678
|
Status: Geschlossen |
REDESIGN LOCKING MECHANISM FOR DB2 RECOVERY HISTORY FILE ACCESS |
| Produkt: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problembeschreibung: |
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-Zusammenfassung: |
****************************************************************
* 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. |
| verfügbare FixPacks: |
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
|
| Lösung |
Redesign. |
| Workaround |
keiner bekannt / siehe Local-Fix |
| Weitere Daten |
Datum - Problem gemeldet :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
| 20.01.2010
10.05.2011
10.05.2011 |
| Problem behoben ab folgender Versionen (IBM BugInfos) |
9.5.
|
| Problem behoben lt. FixList in der Version |
