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 | |
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 |