|
Problem IT03970
|
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 which have Explicit Hierarchical
Locking (EHL) enabled in pureScale and require member crash
recovery to be performed in specific steps.
Scenario 1)
The table was entering into EHL mode and the current member
failed. Page 0 of an object in this table was updated on this
member such that its log LSN is above the recovery starting
point, but the final version of the page is in the CF. Going
through member crash recovery may lose updates that were made to
the page.
Scenario 2)
The table was entering into EHL mode on a member (A) while a
second member (B) is in a failover window (between failure and
the time DB2 declare it as dead), and a third member (C) had
cached locally pages of the table. When the table exits out of
EHL on member A later, the cached pages from member C might
become stale and be used to overwrite the most recent version of
the pages.
Running the db2dart or inspect commands may be able to detect
the problem, but the nature of the corruption is unpredictable,
and therefore, cannot be mapped to a specific db2dart error
message.
If "FODC_BadPage" is being reported in the db2diag.log, the
instance is running EHL, and member crash recovery has been
performed previously, then it is likely that this is a symptom
of this problem. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* pureScale only *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 version 10.5.0.5. *
**************************************************************** |
| Local Fix: |
To avoid hitting this problem the user can disable EHL on their
database. To disable EHL, the user can perform the following:
db2 update db cfg for <dbname> using OPT_DIRECT_WRKLD no
If this problem is hit and the table is corrupted, then the
solution is to restore from a previous backup image. |
| Solution |
The problem is first fixed in DB2 version 10.5.0.5. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 22.08.2014
19.12.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.5
|
 |
