DB2 FOR LUW / DB2FORLUW / 970 - DB2

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.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 v9.7 FP9.                                     * 
****************************************************************

Upgrade to TSA v3.2.2.x or higher.

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
 

Fixed in DB2 v9.7 FP9.

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC96209 IC96210 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

12.09.2013
06.01.2014
06.01.2014

9.7.FP9