• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

The Geek Diary

HowTos | Basics | Concepts

  • Solaris
    • Solaris 11
    • SVM
    • ZFS
    • Zones
    • LDOMs
    • Hardware
  • Linux
    • CentOS/RHEL 7
    • RHCSA notes
    • SuSE Linux Enterprise
    • Linux Services
  • VCS
    • VxVM
  • Interview Questions
  • oracle
    • ASM
    • mysql
    • RAC
    • oracle 12c
    • Data Guard
  • DevOps
    • Docker
    • Shell Scripting
  • Hadoop
    • Hortonworks HDP
      • HDPCA
    • Cloudera
      • CCA 131

Rman Backups Failing with RMAN-20004

By admin

The Problem

Recovery catalog has been configured. Production Database has been cloned and a connection has been made from the clone to Catalog database using rman. DBID of the clone instance has not been changed, (so is identical with source DBID).

Rman backup fails with:

RMAN-00571: 
RMAN-00569: 
RMAN-00571: 
RMAN-03002: failure of resync command at 01/5/2009 08:10:05
RMAN-06004: ORACLE error from recovery catalog database
RMAN-20004: target database name does not match name in recovery catalog

The Solution

Production database has been cloned. The clone database has same dbid but different database name. Connect from clone to recover catalog remove information about the Production database and shows dbid and dbname of Clone. Hence the error.

Prod --> dbname of production database
Clone -> dbname of cloned database
dbid --> 106560009 for both Prod and Clone

Step 1: Verify the dbid of prod

Connect to prod database:

SQL> Select dbid,name from v$database ;

DBID NAME
---------- ---------
106560009 PROD
SQL> Select * from v$database_incarnation ;

INCARNATION# RESETLOGS_CHANGE# RESETLOGS PRIOR_RESETLOGS_CHANGE# PRIOR_RES
------------ ----------------- --------- ----------------------- ---------
STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED
------- ------------ ------------------ --------------------------
1 5.9651E+12 12-AUG-09 5.9651E+12 12-AUG-09
PARENT 694721674 0 NO

2 5.9651E+12 20-AUG-09 5.9651E+12 12-AUG-09
CURRENT 695392949 1 NO

Step 2: Verify the dbid registered in Catalog database

Connect to Catalog database as catalog user

SQL>Connect rman/rman

Select distinct DBID from rc_database;

DBID
----------
700602800
106560009
SQL> Select dbid,name ,DBINC_KEY,RESETLOGS_CHANGE# from rc_database ;

DBID NAME DBINC_KEY RESETLOGS_CHANGE#
---------- -------- ---------- -----------------
700602800 TEST 1973056 5.9653E+10
106560009 CLONE 1970053 5.9654E+10

Step 3

From Step 1 and Step2 its clear the catalog database information has got registered with Clone instance information and does not show any information about the Prod database. There are two options:

Option a

If Clone Instance information in Catalog is not required:

1. Connect to sqlplus of catalog database:

Connect as the catalog users

execute dbms_rcvcat.unregisterdatabaseunregisterdatabase ([dbinc_key], [dbid]) ;

So in our example for Clone database in Rc_database it is:

execute dbms_rcvcat.unregisterdatabaseunregisterdatabase (1970053, 106560009) ;

Alternate option

Instead using dbms packages from SQL to unregister database, you can use RMAN Unregister Database command. RMAN command ‘UNREGISTER DATABASE’ is available since 10g Release 1 (10.1).

RMAN> UNREGISTER DATABASE ; 

Ensure you connect to CLONE and CATALOG to unregister the clone database information. Once done execute the below query:

Select dbid,name ,DBINC_KEY,RESETLOGS_CHANGE# from rc_database ;

The result should not show information about the CLONE.

2. From PROD connect to catalog:

rman target / catalog username/password@connectstring

Rman> Register database ;

Once done try taking a backup.

Option b

Create a new Catalog schema for Prod. Register the Prod database with the new Catalog schema. If you are aware about few backup piece which are no longer shown in control file you can Catalog the same in 10g using.

rman > Catalog start with '[location of backup piece]' ;

Option c: Import Catalog schema from export

If you have an export of the catalog schema before the cloning was done and problem introduced, you can drop the problematic catalog schema and import it from the export dump in the catalog database.

Option d

If the Catalog database resides in a different database then target databases and doesn’t contain any other vital data. You can explore the option of doing a Point time recovery of the Catalog database before the Cloning process was tried.

note: If there are lots of database registered with this catalog schema then instead of option c/d its best to explore option a or b so that other database are not affected.

As a best practice ensure you do not connect your clone database to same recover catalog used by the target database. Since your clone database has the same dbid as the target database from which it was cloned information about the clone database would get updated in the recovery catalog.

Filed Under: oracle, Oracle 10g, Oracle 11g

Some more articles you might also be interested in …

  1. SLES 12: Database Startup Error with ORA-27300 ORA-27301 ORA-27303 While Starting using Srvctl
  2. New Background Processes In Oracle 11g
  3. How to move ASM spfile to a different disk group
  4. How to change the SCAN IP address (SCAN VIP resources) in 11gR2 Grid (CRS) environment
  5. How to Roll Forward a standby database using RMAN incremental backup in 11g
  6. Understanding Oracle Database Recyclebin Features and How to Disable it
  7. Oracle Database 12c New Feature – RMAN “RECOVER TABLE”
  8. RMAN-06059 During RMAN Backup of archivelogs ( How to backup archivelogs moved to a different location)
  9. How to Drop/Truncate Multiple Partitions in Oracle 12C
  10. Oracle 12c Multitenant Architecture: Troubleshooting Ora-12518

You May Also Like

Primary Sidebar

Recent Posts

  • Understanding “docker stats” Command Output
  • ‘docker images’ command error – “Permission Denied”
  • Docker Basics – Expose ports, port binding and docker link
  • How to split BCV and open oracle ASM database
  • How to change the interface name in CentOS/RHEL 8 using prefixdevname
  • Archives
  • Contact Us
  • Copyright

© 2019 · The Geek Diary