home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC81086 Status: Geschlossen

WITH FILE SYSTEM CACHING ENABLED, SYSTEM OUTAGE MIGHT RESULT IN CORRUPTION
DURING LOB OR REORG PROCESSING

Produkt:
DB2 FOR LUW / DB2FORLUW / 980 - DB2
Problembeschreibung:
With file system caching enabled, IBM DB2 for Linux, UNIX and 
Windows uses buffered disk writes for LOB table spaces and 
temporary table spaces used by REORG. Buffered disk writes first 
go to the file system cache and after that when the buffered 
data needs to be physically written to disks, which is typically 
during the commit time, a sync operation must be called. 
 
As a result of an issue in tracking which files needs to be 
synchronized, DB2 mistakenly skips synchronizing some or all of 
the required files. If a machine or file system outage occurs, 
the writes or data that are currently residing in the disk 
buffer and have not yet been written to the disk are lost. The 
time period for which these writes and data are vulnerable is 
dependent on how aggressively the operating system and hardware 
flush file system cache. Under normal conditions, all writes 
will be sent to disks eventually. If an outage happens after the 
writes have been flushed from file system cache to disk, there 
will be no problems. An outage happening before the writes get 
physically written to disks might lead to a potentially large 
variety of symptoms such as: 
 
- LOB data corruption including packed descriptor corruption. 
 
- Reorganization issues when you are copying a reorganized 
object to the table space, or when you are copying the 
reorganized object back to the permanent object. The REORG 
command is only affected when another agent is also sending 
buffered writes to the same table space, and this agent 
synchronizes these writes before the REORG command does. Under 
these conditions, the sync driven by the REORG command is lost. 
 
Note that in this APAR, 'synchronizing' means calling the 
operating system function sync().
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* See APAR Description                                         * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 for Linux, UNIX, and Windows version 9.8 Fix  * 
* Pack 5                                                       * 
****************************************************************
Local-Fix:
- For LOB table spaces: disable file system cache as direct 
writes will be used instead of buffered writes. 
 
- For reorganization process using the REORG command: use a 
dedicated table space for the REORG command, thus ensuring that 
no other agents are doing buffered writes to the same table 
space. 
 
This fix results in an increased number of sync operations. This 
might increase commit latency, especially for transactions 
involving a significant number of buffered writes, for example 
transactions involving a large number of LOB data.
Lösung
Problem first fixed in DB2 for Linux, UNIX, and Windows version 
9.8 Fix Pack 5
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
30.01.2012
13.06.2012
13.06.2012
Problem behoben ab folgender Versionen (IBM BugInfos)
9.8.,
9.8.FP5
Problem behoben lt. FixList in der Version
9.8.0.5 FixList