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

The Geek Diary

  • OS
    • Linux
    • CentOS/RHEL
    • Solaris
    • Oracle Linux
    • VCS
  • Interview Questions
  • Database
    • oracle
    • oracle 12c
    • ASM
    • mysql
    • MariaDB
  • DevOps
    • Docker
    • Shell Scripting
  • Big Data
    • Hadoop
    • Cloudera
    • Hortonworks HDP

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. How to Rename the Default JSESSIONID in WebLogic
  2. Oracle Database interview questions – Privileges And Roles
  3. Common Init.ora Parameters and Unix, Linux Kernel Parameters and Relationship Between Them
  4. How To Create Device Alias For ASM Disks Using mknod On Linux/Unix
  5. RMAN backup Concepts for Oracle RAC
  6. How to set EVENTS in spfile
  7. Oracle Database Interview Questions : Redo Logs and Archiving
  8. How to Check the Environment Variables for an Oracle Process
  9. How to upgrade Oracle database to 12c Pluggable database (Multitenant) using Transportable tablespace(TTS) method
  10. How to Drop/Truncate Multiple Partitions in Oracle 12C

You May Also Like

Primary Sidebar

Recent Posts

  • nixos-rebuild Command Examples in Linux
  • nixos-option: Command Examples in Linux
  • nixos-container : Command Examples in Linux
  • nitrogen Command Examples in Linux

© 2023 · The Geek Diary

  • Archives
  • Contact Us
  • Copyright