DB2 FOR LUW / DB2FORLUW / A50 - DB2

This applies only to databases that have Explicit Hierarchical 
Locking (EHL) enabled in pureScale and that need multiple member 
crash recoveries to be performed in specific steps. 
 
The table in question will first need to transition into EHL 
mode as a result of a read-only transaction. Then, crashed on 
this member and member crash recovery must be performed. This 
table is now up and running again and was about to transition 
into EHL mode again as a result of an update transaction. 
However, before EHL transition starts and after it acquires the 
proper locks, the member crashed again. The second member crash 
recovery might cause older version of the pages of the table to 
be updated instead of the latest version, possibly resulting in 
data corruption on the table. 
 
Symptoms may include index-data mismatch or incorrect results. 
Running db2dart or inspect may detect the problem, but the 
nature of the corruption is unpredictable and therefore cannot 
be mapped to a specific db2dart error message.

**************************************************************** 
* USERS AFFECTED:                                              * 
* specific to pureScale                                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 version 10.5.0.4.                             * 
****************************************************************

To avoid hitting this problem, as opposed to undoing the 
corruption, the user can disable EHL before performing member 
crash recovery. 
 
To disable EHL, the user can perform the following: 
 
db2 update db cfg for <dbname> using OPT_DIRECT_WRKLD no 
 
And to resume EHL safely, the db2 instance must be stopped 
before EHL can be enabled again. 
 
Alternatively, the user can stop all active members before 
issuing member crash recovery by performing the following: 
 
db2stop 
db2start 
db2 restart db <dbname> 
 
Applying the APAR fix will prevent the problem from occurring. 
If this problem is hit and the table is corrupted, then the 
solution is to restore from a previous backup image.

DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
 

The problem is first fixed in DB2 version 10.5.0.4.

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

27.06.2014
08.09.2014
09.04.2015