Rman Backup On Physical Standby Database Failing with RMAN-20079 after Structure Changes on Primary (Doc ID 1326706.1)
In this Document
Symptoms
Cause
Solution
References
APPLIES TO:
Oracle Database - Enterprise Edition - Version 11.2.0.2 and later
Information in this document applies to any platform.
Checked for relevance on 24-Jun-2013
SYMPTOMS
RMAN catalog is used to backup the database on Standby Database side.
New tablespace was added on the Primary Database side.
No RMAN backup or connection made on the Primary Database
RMAN backup on standby database failing with errors after adding new tablespace on primary.
RMAN backup failing with:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of configure command at 05/17/2011 10:55:28
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of partial resync command on default channel at 05/17/2011 10:55:28
RMAN-20079: full resync from primary database is not done
CAUSE
The recovery catalog repository does not know about the new tablespace that was added since no RMAN resync was done between the Primary Database and Catalog Database.
SOLUTION
Unpublished Documentation Bug 7566701 was filed on this issue and closed as documentation bug.
It is necessary to perform resync between Primary Database and Catalog Database whenever there is a structural change done in the Primary Database.
Additionally, in 11g, for resync to get primary database changes, it is required to execute
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
.
User will also have to setup necessary configuration using the below command:
CONFIGURE DB_UNIQUE_NAME <db_unique_name> CONNECT IDENTIFIER <sqlnet_alias>;
Make sure when you connect to the target database via the “rman” command you use a password and not to use OS authentication.
If running the resync…all on Standby Database, RMAN-20079 will still occur. The command needs to be run on primary DB.
$ rman target user/pwd@primary catalog rman/pwd@catalog
RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
From the bug:
Changes to example 3-29 on page 3-56 of the B&R Reference Manual were made
for 11.2.
.
Resynchronizing the Recovery Catalog After a Structural Change
.
Suppose you have the following:
A Data Guard environment containing primary database prod and standby
database standby3
Both the primary and the standby databases are registered with the catalog
You take a backup of the database and archivelogs
You start SQL*Plus, connect to database prod, and add a datafile to tablespace users as follows:
SQL> ALTER TABLESPACE <TABLESPACE_NAME> ADD DATAFILE ‘’?/
SIZE 1M AUTOEXTEND ON
NEXT 10K MAXSIZE 10M";
.
The goal is to update the recovery catalog with metadata about this change.
After the change is propagated to the standby, you start the RMAN client,
connect to the standby as TARGET, and connect to the recovery catalog.
The next step is to define the connect identifiers for the standby database
In your Data Guard environment with the CONNECT IDENTIFIER clause of the
CONFIGURE command:
CONFIGURE DB_UNIQUE_NAME standby CONNECT IDENTIFIER ’’;
.
At this point, you use the RESYNC CATALOG … ALL command to resynchronize
the recovery catalog with changes for all the databases in the Data Guard
environment. While you can resynchronize the catalog with a specific standby
site’s information, Oracle recommends you use the ALL option in order to keep
the recovery catalog schema current with any database changes that may have
occurred within your Data Guard environment:
RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
.
The recovery catalog is updated with metadata about the datafile added to the
users tablespace of database prod.