|
Problem IC95911
|
Status: Closed |
IN AN AUTOMATED HADR ENVIRONMENT THE TAKEOVER HADR COMMAND SUCCEEDS, BUT A MOVE REQUEST IS NOT SENT TO TSA |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
In an automated HADR environment, the "db2 takeover hadr on db
<dbname>" may succeed without a corresponding move request being
processed by TSA. Here are the log messages seen in the TSA
RecoveryRM trace summary file in the case of a successful
user-initiated HADR takeover:
07/31/13 11:02:02.194944 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:05.430001 T(3600) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:07.716282 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:08.751917 T(782) _RCD LockTrees Request injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:08.784144 T(782) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:10.066568 T(3600) _RCD Move Request injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:10.145023 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:10.284629 T(3600) _RCD LockTrees Request
injected:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:02:11.428430 T(782) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR1-rg/ResGroup/IBM.ResourceGroup
The log message which corresponds to the move request is the one
which contains this string:"Move Request injected".
Here is how the TSA log messages look like in the failure case:
07/31/13 11:09:48.563402 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:09:51.421614 T(3600) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:09:53.464228 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:09:54.490655 T(782) _RCD LockTrees Request injected:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:09:54.822743 T(3600) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
(we expect to see a log corresponding to the move request
here)
07/31/13 11:09:55.331735 T(3600) _RCD LockResource request
injected:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:10:26.472014 T(782) _RCD LockTrees Request injected:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
07/31/13 11:10:26.501101 T(782) _RCD UnlockResource Request
removed:
db2_db2inst1_db2inst1_DB2HADR2-rg/ResGroup/IBM.ResourceGroup
In this case, the move request was not processed by TSA and as a
result DB2 and TSA are out of sync. If the primary HADR database
resides on hostA and the standby resides on hostB, TSA will
believe the primary resides on hostB and that the standby
resides on hostA. The result is a database outage.
The cause of this issue is a TSA bug which has been fixed in TSA
v3.2.2. This problem is only reproducible on versions of TSA
lower than v3.2.2. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 v9.7 FP9. *
**************************************************************** |
| Local Fix: |
Upgrade to TSA v3.2.2.x or higher. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Fixed in DB2 v9.7 FP9. |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC96209 IC96210
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 12.09.2013
06.01.2014
06.01.2014 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.9
|
 |
| 9.7.0.9
|
|
