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 IT23254 Status: Closed

Db2 HADR standby db can shutdown when log archive path is sharedwith a
different database

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
If a Db2 HADR standby database is configured with an archive log
path that is shared with a different database (ie. different
database name or database seed), the Standby database may
retrieve an incorrect log file, resulting in a ForceDBShutdown
and SQLP_BADLOG symptom when replaying the log file.

When the Standby database retrieves the incorrect log file, the
following db2diag.log message is observed:

2015-12-21-13.41.17.310553-300 I50225E526            LEVEL: Info
PID     : 18053                TID : 140638037206784 PROC :
db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   :
dbname1
HOSTNAME: host1
EDUID   : 160                  EDUNAME: db2logmgr (IADB) 0
FUNCTION: DB2 UDB, data protection services,
sqlpgRetrieveLogFile, probe:4148
DATA #1 : 
Completed retrieve for log file S0000014.LOG on chain 0 to
/db2/db2inst1/iadb/fsd01/db2inst1/NODE0000/SQL00001/LOGSTREAM000
0/LOGSTREAM0000/.

2015-12-21-13.41.17.310804-300 I50752E685      LEVEL: Error
PID     : 18053      TID : 140638037206784      PROC :db2sysc 0
INSTANCE: db2inst1             NODE : 000        DB: dbname1
HOSTNAME: host1
EDUID   : 160                  EDUNAME: db2logmgr (IADB) 0
FUNCTION: DB2 UDB, data protection services,
sqlpgoleCheckLogCorruption, probe:400
MESSAGE : ZRC=0x071000D6=118489302=SQLP_EXT_DBID_INCORR
          "Database ID does not match. Extent does not belong to
this database."
DATA #1 : String, 60 bytes
Database seeds do not match! pXHDR->extDbSeed / LFH->dbSeed:
DATA #2 : unsigned integer, 4 bytes
1454562260
DATA #3 : unsigned integer, 4 bytes
2389964198

This indicates that the incorrect log file is from another
database. When the log file is replayed, this will result in an
SQLP_BADLOG error:

2017-11-08-08.19.05.039191-360 I4114951E560      LEVEL:Error
PID     : 26419       TID : 140672858318592  PROC:db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : dbname1
APPHDL  : 0-42070               APPID: *LOCAL.DB2.171108141901
HOSTNAME: host1
EDUID   : 1088                   EDUNAME: db2agent (CONFIGCI) 0
FUNCTION: DB2 UDB, oper system services, sqlogctGlobalInit,
probe:5
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File
cannot be used"
          DIA8414C Logging can not continue due to an error.
Problem Summary:
****************************************************************
* USERS AFFECTED:                                              *
* HADR users                                                   *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* If an HADR Standby database's archive path is set to a       *
* location that contains archived logs from another database,  *
* it will retrieve these logs, see that the database seeds do  *
* not match, but not delete them. Later on when these logs are *
* opened for writing, logging will encounter an error and      *
* force the db to shut down. The Standby database will         *
* continue to shut down upon subsequent activations and        *
* re-initializing HADR is required.                            *
****************************************************************
* RECOMMENDATION:                                              *
* Avoid problem by not sharing archive path between databases. *
****************************************************************
Local Fix:
Move the problematic log file out of the Standby database's
active
log path (see LOGPATH db config parameter).  Determine why the
Standby database archive log path is set to this
location which contains log files from another database. In
order to prevent this log (and other problematic
logs) from being retrieved again, the Standby database archive
log path
should be changed to a valid location (not containing log files
from
other databases).
Note. never permanently delete or remove log files until they
are no longer required for database or rollforward recovery.
Solution
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
22.11.2017
12.07.2018
12.07.2018
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)