|
Problem IC98726
|
Status: Closed |
INCORRECT HANDLING OF HEURISTICALLY ABORTED TRANSACTION IN DB2 PURESCALE LEAVING DATA INCONSISTENT |
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
In a pureScale environment, if the database crashed while
executing a heuristic abort request from LIST INDOUBT
TRANSACTION WITH PROMPTING command, the subsequent crash
recovery might not have performed all the compensation
action needed to back out the changes made by this
transaction. Further more, the heurstically aborted
transaction is no longer tracked and reported by subsequent
LIST INDOUBT TRANSACTION command.
Depending on the crash point, if the transaction was in the
midst of being compensated then the ensuing recovery would not
complete the compensation nor abort the transaction. This can
leave the data inconsistent, where any future access can result
in undefined behavior. One possibility could be getting:
SQL1034C The database was damaged, so all applications
processing the database were stopped.
and marking the database damaged and/or creating a FODC_BadPage
directory in the
db2dump directory. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* pureScale *
****************************************************************
* PROBLEM DESCRIPTION: *
* In a pureScale environment, if the database crashed while *
* executing a heuristic abort request from LIST INDOUBT *
* TRANSACTION WITH PROMPTING command, the subsequent crash *
* recovery might not have performed all the compensation *
* action needed to back out the changes made by this *
* transaction. Further more, the heurstically aborted *
* transaction is no longer tracked and reported by subsequent *
* LIST INDOUBT TRANSACTION command. *
* *
* Depending on the crash point, if the transaction was in the *
* midst of being compensated then the ensuing recovery would *
* not *
* complete the compensation nor abort the transaction. This *
* can *
* leave the data inconsistent, where any future access can *
* result *
* in undefined behavior. One possibility could be getting: *
* *
* SQL1034C The database was damaged, so all applications *
* processing the database were stopped. *
* *
* and marking the database damaged and/or creating a *
* FODC_BadPage *
* directory in the db2dump directory. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 for LUW version 10.5.4. *
**************************************************************** |
| Local Fix: |
|
| 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 |
Problem was first fixed in Version 10.5 Fix Pack 4. At a
minimum, this fix should be applied on the server. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 14.01.2014
19.01.2014
19.01.2014 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.5.0.4
|
 |
