|
Problem IC64029
|
Status: Closed |
STANDBY DB (HADR) MARKED AS BAD IN THE LCU PHASE WHEN LOGARCHMETH1 IS SET TO LOGRETAIN. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| 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 the when the Primary Database is
started to integrate the HADR pair it fails with a timeout. |
| Problem Summary: |
****************************************************************
* 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. *
**************************************************************** |
| Local Fix: |
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. |
| available fix packs: |
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
|
| Solution |
Problem is first fixed in DB2 UDB version 9.7 fix pack 2 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 22.10.2009
18.02.2010
18.02.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP2
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
