home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
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
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC81062 Status: Closed

With file system caching enabled, system outage might result in corruption
during LOB or REORG processing

product:
DB2 FOR LUW / DB2FORLUW / 950 - DB2
Problem description:
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 Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* See APAR description                                         * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See APAR description                                         * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to IBM DB2 for Linux, Unix and Windows version 9.5   * 
* Fix Pack 9.                                                  * 
****************************************************************
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.
available fix packs:
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
Problem first fixed in IBM DB2 for Linux, Unix and Windows 
version 9.5 Fix Pack 9.
Workaround
not known / see Local fix
BUG-Tracking
forerunner  : APAR is sysrouted TO one or more of the following: IC81066 IC81086 
follow-up : 
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
27.01.2012
05.03.2012
06.03.2012
Problem solved at the following versions (IBM BugInfos)
9.0.,
9.5.,
9.5.FP9
Problem solved according to the fixlist(s) of the following version(s)
9.5.0.9 FixList