This error can impact various operations that needs to retrieve
log files from archive, such as online backup and replication
(Qrep or CDC).
This problem only exits in version 11.5.6 and 11.5.7. It only
impacts databases using the HADR feature. It is triggered when
the
HADR standby was reinitialized (via restoring a backup image)
without first dropping the database.
The follow messages in db2diag.log shows an example of this
problem, where the particular log file, S1234567.LOG, was
successfully archived by Db2, yet the later attempt to retrieve
it failed with SQLP_LOG_NOT_IN_ARCHIVE error.
2022-04-28-06.00.02.250144+240 I260277A558 LEVEL: Info
PID : 12845548 TID : 5044 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : MYDB
HOSTNAME: myhost
EDUID : 5044 EDUNAME: db2logmgr (MYDB) 0
FUNCTION: DB2 UDB, data protection services,
sqlpgArchiveLogFile, probe:3180
DATA #1 :
Completed archive for log file S1234567.LOG to
/myarchive/db2inst1/MYDB/NODE0000/LOGSTREAM0000/C0000021/ from
...
2022-04-28-07.08.52.511287+240 I271131A688 LEVEL:
Warning
PID : 12845548 TID : 5044 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : MYDB
HOSTNAME: myhost
EDUID : 5044 EDUNAME: db2logmgr (MYDB) 0
FUNCTION: DB2 UDB, data protection services,
sqpLogMgrEdu::sqlpgRetrieveLogFile, probe:4062
MESSAGE : ZRC=0x8010019D=-2146434659=SQLP_LOG_NOT_IN_ARCHIVE
"Log extent not found in archive."
DATA #1 : String, 38 bytes
Search on disk did not find any chain.
DATA #2 : db2LogStreamIDType, PD_TYPE_DB2_LOG_STREAM_ID, 2 bytes
0
DATA #3 : SQLPG_EXTENT_NUM, PD_TYPE_SQLPG_EXTENT_NUM, 4 bytes
1234567
This happens because there is a mismatch of the log chain
subdirectory used by the retrieve with what was used by the
archive. In the above example, the log chain subdirectory used
by archive is C0000021. The log chain subdirectory used by
retrieve is not shown in db2diag.log, but can be identified
using trace, or the database control file SQLOGCTL.GLFH.1.
The mismatch of the log chain subdirectory would not have
occurred if proper steps were followed when initializing the
HADR
standby, as suggested in "Initializing high availability
disaster recovery (HADR)"
https://www.ibm.com/docs/en/db2/11.5?topic=availability-initiali
zing-hadr, to first issue DROP DATABASE, before RESTORE DATABASE
and START HADR AS STANDBY. |
