DB2 FOR LUW / DB2FORLUW / 980 - DB2

In a HADR environment, if crash recovery is interrupted on the 
primary server the database will still stay online instead of 
shutting down.  Since crash recovery has not completed the 
database will still be inconistent.  So any subsequent access to 
the database will return SQL1015N.  Also, the following 
db2diag.log message will be returned indicating that the Standby 
DB is ahead of the Primary DB: 
 
YYYY-MM-DD-HH.MM.SS.NNNNNN     LEVEL: Error 
PID     : <pid>                TID  : <tid> : db2sysc 0 
INSTANCE: <instance>           NODE : 000 
EDUID   : <eduid>              EDUNAME: db2hadrp (<db>) 0 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, 
probe:20485 
MESSAGE : ADM12500E  The HADR standby database cannot be made 
consistent with he 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.

USERS AFFECTED:  All 
 
PROBLEM DESCRIPTION:  please refer to the ERROR DESCRIPTION. 
 
PROBLEM SUMMARY:  please refer to the ERROR DESCRIPTION.

1.  Do not interrupt crash recovery from completing.  This can 
be achieved by limiting remote access to the database if crash 
recovery is needed.  Or by explicitly activating the database so 
that early remote connection termination will not interrupt the 
crash recovery process. 
 
2.  If crash recovery has already been interrupted then you will 
need to stop the instance using the force option.  Upon 
restarting the instance explicitly start the database so that 
crash recovery can complete successfully.

DB2 Version 9.8 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 9.8 Fix Pack 4 for AIX and Linux
 DB2 Version 9.8 Fix Pack 5 for AIX and Linux
 

Problem first fixed in Fix Pack 3.

see LOCAL FIX

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

17.02.2010
20.12.2010
20.12.2010