|
Problem IC90020
|
Status: Closed |
"TAKEOVER" HADR COMMAND SOMETIMES CAUSES "LOG CHAIN MISMATCH" ERROR, LEADING TO FAILURE OF STANDBY IN HADR SETUP. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
It has been observed that when a particular sequence of steps
are executed, HADR standby fails to come up.
The reproduction steps are :
a) Issue "db2 takeover hadr on db <dbname>" from standby
b) Issue "db2_kill" from new primary
c) After 1 minute , issue "db2 takeover hadr on db <dbname> by
force peer window only" from standby
d) After 1 minute, issue "db2start" followed by "db2 start hadr
on db <dbname> as standby"
The db2diag.log shows the following error messages :
2013-01-11-15.59.05.509769+240 I38363E380 LEVEL:
Warning
PID : 5226 TID : 47972704315712PROC :
db2sysc
INSTANCE: inst1 NODE : 000 DB : ABC
EDUID : 47 EDUNAME: db2hadrp (ABC)
FUNCTION: DB2 UDB, recovery manager, sqlpLogChainMatch, probe:20
MESSAGE : Log chain mismatch detected: 11 0,1476536718
2013-01-11-15.59.05.509837+240 E38744E686 LEVEL: Error
PID : 5226 TID : 47972704315712PROC :
db2sysc
INSTANCE: inst1 NODE : 000 DB : ABC
EDUID : 47 EDUNAME: db2hadrp (ABC)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20500
MESSAGE : ADM12500E The HADR standby database cannot be made
consistent with the primary database.
The log stream of the standby database is incompatible with that
of the primary database.
To use this database as a standby, it must be recreated from a
backup image or split mirror of the primary database.
The likely root cause is a special boundary condition where the
forced takeover was executed on a standby that was from a
consistent point without replaying any log records. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Customers using HADR feature of DB2 *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 V97fp9 fixpack. *
**************************************************************** |
| Local Fix: |
As a temporary workaround:
1. Take a full backup on Primary
2. Restore it on Standby
3. Re-initiliaze Hadr by starting db as standby |
| 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 |
The fix will be included in DB2 v97fp9 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 04.02.2013
06.01.2014
10.11.2015 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP8,
9.7.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.9
|
 |
| 9.7.0.9
|
|
