DB2 FOR LUW / DB2FORLUW / 970 - DB2

For HADR database in supersync mode, when primary is deactivated 
gracefully in local catchup state, HADR standby could be 
crashed. 
On primary, the below message will be printed to db2diag.log: 
2012-03-18-01.59.00.354402-420 I2061400E373        LEVEL: 
Warning 
PID     : 7405                 TID  : 47028109306176PROC : 
db2sysc 
INSTANCE: db2inst1       NODE : 000          DB   : DBNAME 
EDUID   : 30                   EDUNAME: db2hadrp (DBNAME) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, 
probe:20694 
MESSAGE : Sending hard checkpoint XHDR. 
 
On standby, below messages will appear in db2diag.log: 
2012-03-19-18.25.22.115785-420 I76441E457          LEVEL: Info 
PID     : 19997                TID  : 47368376412480PROC : 
db2sysc 
INSTANCE: db2inst1         NODE : 000          DB   : TESTDB 
EDUID   : 63                   EDUNAME: db2hadrs (TESTDB) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrHandleXhdrMsg, probe:10175 
DATA #1 : <preformatted> 
Received HDR_MSG_XHDRCLOSE, ExtNum 4, firstLso 41045321 ExtSize 
4, PageCount 2, state 0x8001 
 
2012-03-19-18.25.22.314115-420 I76899E479          LEVEL: Severe 
PID     : 19997                TID  : 47368376412480PROC : 
db2sysc 
INSTANCE: db2inst1          NODE : 000          DB   : TESTDB 
EDUID   : 63                   EDUNAME: db2hadrs (TESTDB) 
FUNCTION: DB2 UDB, RAS/PD component, 
pdResilienceIsSafeToSustain, probe:800 
DATA #1 : String, 37 bytes 
Trap Sustainability Criteria Checking 
DATA #2 : Hex integer, 8 bytes 
0x200000000000800C 
DATA #3 : Boolean, 1 bytes 
false

**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 HADR users with all platforms                            * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Without the fix, for hadr databases in supersync mode,       * 
* standby database would crash while in local catchup state    * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to db2 v97fp6                                        * 
****************************************************************

One way to avoid running into this issue is to make sure that 
primary is deactivated only after standby finishes local 
catchup. 
If in case Standby ran into the issue then restarting the 
standby database should bring the standby database back to 
normal.

DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 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
 

after upgrading to v97fp6, customer will not hit the problem 
described in the Err Description

not known / see Local fix

forerunner  : APAR is sysrouted TO one or more of the following: IC84533 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

19.03.2012
05.06.2012
05.06.2012

9.7.FP6