DB2 FOR LUW / DB2FORLUW / 970 - DB2

In an HADR environment the Standby Database might be 'marked as 
bad' during the Local Catch-up (LCU) phase.  In this case the 
Standby Database was restored using a full offline backup from 
the Primary Database, with LOGARCHMETH set to TSM.  Before 
starting the Standby Database LOGARCHMETH is set to LOGRETAIN 
from TSM.  No log files are shipped over the Standby Database, 
so no log files are replayed on the Standby Database during the 
LCU phase.  The Standby Database should move from the LCU phase 
to the RCU (Remote Catch-up) phase, but this does not occur and 
instead the Standby database is 'marked as bad.'  This shuts 
down the Standby Database, and the when the Primary Database is 
started to integrate the HADR pair it fails with a timeout.

**************************************************************** 
* USERS AFFECTED:                                              * 
* Users of HADR with LOGARCHMETH set to LOGRETAIN              * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* In an HADR environment the Standby Database might be 'marked * 
* as bad' during the Local Catch-up (LCU) phase.  In this case * 
* the Standby Database was restored using a full offline       * 
* backup from the Primary Database, with LOGARCHMETH set to    * 
* TSM.  Before starting the Standby Database LOGARCHMETH is    * 
* set to LOGRETAIN from TSM.  No log files are shipped over    * 
* the Standby Database,so no log files are replayed on the     * 
* Standby Database during the LCU phase.  The Standby Database * 
* should move from the LCU phase to the RCU (Remote Catch-up)  * 
* phase, but this does not occur and instead the Standby       * 
* database is 'marked as bad.'  This shuts down the Standby    * 
* Database, and then when the Primary Database is started to   * 
* integrate the HADR pair it fails with a timeout.             * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to the latest fix pack.                              * 
****************************************************************

On the Standby, where the Primary is still using TSM for 
LOGARCHMETH 
 
1.  Keep LOGARCHMETH set to TSM, and ensure that TSM is working 
properly on the Standby environment. 
 
2.  If LOGARHMETH is changed to LOGRETAIN, ship over one 
tranasactional log file to the Standby Database environment. 
 
If you don't want to ship over any transactional log files from 
the Primary to the Standby environment, and TSM is not working 
on the Standby environment: 
 
3.  Change LOGARCHMETH to LOGRETAIN on the Primary before taking 
a backup of the database to be used to create the Standby 
Database.

DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

Problem is first fixed in DB2 UDB version 9.7 fix pack 2

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

22.10.2009
18.02.2010
18.02.2010

9.7.FP2