|
Problem IT02843
|
Status: Closed |
PERFORMING MEMBER CRASH RECOVERY IN PURESCALE WITH EHL ENABLED MIGHT CORRUPT THE TABLE IN CERTAIN SITUATIONS |
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
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. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* specific to pureScale *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 version 10.5.0.4. *
**************************************************************** |
| Local Fix: |
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. |
| available fix packs: |
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
|
| Solution |
The problem is first fixed in DB2 version 10.5.0.4. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 27.06.2014
08.09.2014
09.04.2015 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.5.0.4
|
 |
