home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC81233 Status: Closed

IN HADR SUPERASYNC MODE IT IS POSSIBLE FOR STANDBY AGENTS TO APPEAR HUNG
AND NOT RECEIVE ANY LOG RECORDS.

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
In HADR superasync synchronization mode, if the following steps 
are executed, standby will hang for ever. 
 
Note: Because standby is hung, any action on standby including 
takeover will hang. 
 
1. HADR pair using super aysnc mode is setup with logfilsiz X. 
2. HADR primary generates few log's. 
3. Standby is deactivated. 
4. Run some transactions on primary to move up in number of log 
extents. 
5. Primary is deactivated. 
6. logfilsiz on primary is changed to Y 
7. A start hadr on db hadrdb as primary BY FORCE is issued. 
8. Few more log's are written with the new logfilsiz 
9. Activate the standby. 
 
After step 9, standby will appear hung. You can also confirm 
this by looking at the output of db2pd -hadr. If the log extent 
number for standby does not move ahead then it could be due to 
this hang. 
 
db2diag.log will contain messages similar to the following, note 
that the next extent header standby received after extent header 
for log 718  is for log 747 instead of 719. Due to this out of 
order extent header send issue at the time of logfilsiz causes a 
hang on standby. 
 
2012-01-05-04.46.03.978538-300 I391774E443        LEVEL: Info 
PID    : 18870                TID  : 140736989226752PROC : 
db2sysc 
INSTANCE: db2inst1              NODE : 000 
EDUID  : 34                  EDUNAME: db2hadrs (HDRLNX) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrHandleXhdrMsg, probe:10175 
DATA #1 : <preformatted> 
Received HDR_MSG_XHDR, ExtNum 718, firstlsn 00036DEF8000 ExtSize 
 
5000, PageCount 5000, state 0x18211 
 
2012-01-05-04.46.06.062622-300 I392218E448        LEVEL: Info 
PID    : 18870                TID  : 140736989226752PROC : 
db2sysc 
INSTANCE: db2inst1              NODE : 000 
EDUID  : 34                  EDUNAME: db2hadrs (HDRLNX) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrHandleXhdrMsg, probe:10175 
DATA #1 : <preformatted> 
Received HDR_MSG_XHDRCLOSE, ExtNum 718, firstlsn 00036DEF8000 
ExtSize 5000, PageCount 5000, state 0x18211 
 
2012-01-05-04.46.06.079451-300 I393037E443        LEVEL: Info 
PID    : 18870                TID  : 140736989226752PROC : 
db2sysc 
INSTANCE: db2inst1              NODE : 000 
EDUID  : 34                  EDUNAME: db2hadrs (HDRLNX) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrHandleXhdrMsg, probe:10175 
DATA #1 : <preformatted> 
Received HDR_MSG_XHDR, ExtNum 747, firstlsn 000391560000 ExtSize 
 
6700, PageCount 6700, state 0x10001
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 LUW HADR users using SUPERASYNC on all platforms         * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Without the fix, customer could  hit the problem described   * 
* in the error description                                     * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* We recommend upgrading to v97fp6                             * 
*                                                              * 
* A local workaround would be:                                 * 
* 1) Kill the instance on standby server                       * 
* 2) Copy all the log's from primary's active log path to      * 
* standby's active log path                                    * 
* 3) start the server on standby side                          * 
* 4) start hadr on standby database.                           * 
****************************************************************
Local Fix:
A local workaround would be: 
1) Kill the instance on standby server 
2) Copy all the log's from primary's active log path to 
standby's active log path 
3) start the server on standby side 
4) start hadr on standby database.
available fix packs:
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

Solution
After applying v97fp6, the problem in error description can be 
avoided.
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
06.02.2012
06.12.2012
06.12.2012
Problem solved at the following versions (IBM BugInfos)
9.7.FP6
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.6 FixList