Every log file has a header structure, called XHDR. This
structure is typically changed by the primary and shipped to the
standby. This structure is needed by log replay to ensure
correctness. The problem occurs when log replay detects that it
has missed the final copy of the XHDR structure.
As a result, log replay is not able to continue and this causes
the standby database to be shut down. Replay did not receive
the final copy of XHDR structure due to logic that decides which
copy is more recent. This decision is implemented by a counter.
This counter has wrapped, causing the final copy to be viewed as
an older copy and thus not returned.
The counter wrapped because the counter is not reset when DB2
renames an old log file (such as log S0000100.LOG) to a new log
file (such as S0000200.LOG). So over time, the counter keeps
increasing and eventually wraps. The fix is the reset the
counter when DB2 renames old log file to new one.
On HADR standby, you can see the following error messages in
db2diag.log:
2013-12-17-07.54.53.382000+540 I19311270F1041 LEVEL: Error
PID : 2792 TID : 2504 PROC :
db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : DB01
APPHDL : 0-8 APPID: *LOCAL.DB2.131209010233
HOSTNAME: host01
EDUID : 2504 EDUNAME: db2shred (DB01) 0
FUNCTION: DB2 UDB, recovery manager, sqlpshrEdu, probe:45325
MESSAGE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File
cannot be used"
DIA8414C Logging can not continue due to an error.
DATA #1 : String, 66 bytes
last record from this extent does not match lastLfsLsn in its
XHDR
DATA #2 : SQLPG_EXTENT_NUM, PD_TYPE_SQLPG_EXTENT_NUM, 4 bytes
11256
DATA #3 : unsigned integer, 8 bytes
751045259954
DATA #4 : unsigned integer, 8 bytes
751045260049
DATA #5 : unsigned integer, 8 bytes
751045259954
DATA #6 : LFS/LSN, PD_TYPE_SQLP_LFS_LSN_PAIR, 16 bytes
24380732/00000001EE2D1EC8
DATA #7 : LFS/LSN, PD_TYPE_SQLP_LFS_LSN_PAIR, 16 bytes
18446744073709551615/FFFFFFFFFFFFFFFF |
