Steps to workaround issue described in Alert 308698.1
(Doc ID 368276.1)
Last updated on JANUARY 24, 2020
Applies to:Oracle Database - Enterprise Edition - Version 10.1.0.2 to 10.2.0.2 [Release 10.1 to 10.2]
Information in this document applies to any platform.
***Checked for relevance on 27-SEP-2011***
Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual
environments, actual persons, living or dead, is purely coincidental and not intended in any manner.
For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:
Catalog Schema: RMAN
Database Names: OLDPRIM,NEWPRIM,NEWSTBY
Host Name: NEWSTBYHOST
The steps within this note are to be used as a workaround for issues encountered per ALERT <Note.308698.1> and can only be done on 10g and up. For 9i, the only option is to take a full backup per the alert.
This workaround should only be leveraged if recreating the physical standby from the primary is not feasible. The workaround requires the following high level steps:
- Flashback the old primary and convert to a new standby database using a standby controlfile created from the primary database.
- Renaming the datafiles and logfiles if the file names are not identical between primary and standby.
- Using RMAN to catalog the standby data files as a level 0 backup and recording it in a recovery catalog.
- Using RMAN to catalog the primary data files as a level 1 backup (incremental) using the same recovery catalog. The backup will require a full scan of the primary database and the backup size will depend on number of changed blocks since the STANDBY_BECAME_PRIMARY_SCN.
- Copying and applying the incremental to the standby and restarting managed recovery.
The most time consuming aspect of this procedure is creating and copying the level 1 backup since it will require a full database scan and copying the relevant changed blocks.
The most complex aspect of this procedure is renaming the data file and log files. These steps may be skipped if the data file and log file names are identical between the primary and standby databases.
Please note the commands may differ slightly depending on variables specific to each environment such as passwords, RMAN catalog database location, database link names, etc.
This workaround accounts for the following technologies if used:
- Real Application Clusters (RAC)
- Automatic Storage Management (ASM)
- Oracle Managed Files (OMF)
- Mis-matched Standby Redo Logs and Online Redo Logs
- Change tracking files
- Flashback logs
- Compatible must be set to 10.0 or higher on every instance.
SQL>select name, value from v$parameter where upper(name)'COMPATIBLE';
- Assumes the number of redo log members are the same between primary and standby.
- Assumes host equivalency is in place for the 'oracle' user account between primary and standby to support remote shell commands (rsh, rcp) or secure shell (ssh, scp).
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document