Oracle 12c – How to correct the error: “RMAN-20005: target database name is ambiguous”

By William Sescu

I do have a Data Guard environment, where I have configured the RMAN DB_UNIQUE_NAME persistent setting for my primary and the standby. With the RMAN DB_UNIQUE_NAME settings I am able to run reports my Oracle Data Guard environment from any database. I could e.g. list all archivelogs for SITE1 from SITE2 or the other ways around.
Or I could show all persistent settings for SITE1 from SITE2 and of course the other way around. The only prerequisite for this feature is the RMAN catalog. In case you are not connected to the RMAN catalog you end up with the following error:

RMAN> SHOW ARCHIVELOG DELETION POLICY FOR DB_UNIQUE_NAME 'DBIT121_SITE2';

using target database control file instead of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of show command at 02/21/2017 13:58:53
RMAN-05037: FOR DB_UNIQUE_NAME option cannot be used in nocatalog mode

After connecting to the catalog, you can use this feature, e.g. to show the archive deletion policy.

$ rman target sys/welcome1 catalog /@rcat

Recovery Manager: Release 12.1.0.2.0 - Production on Tue Feb 21 14:25:10 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DBIT121 (DBID=644484523)
connected to recovery catalog database

RMAN> SHOW ARCHIVELOG DELETION POLICY FOR DB_UNIQUE_NAME 'DBIT121_SITE1';
RMAN configuration parameters for database with db_unique_name DBIT121_SITE1 are:
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY BACKED UP 1 TIMES TO DISK;

RMAN> SHOW ARCHIVELOG DELETION POLICY FOR DB_UNIQUE_NAME 'DBIT121_SITE2';
RMAN configuration parameters for database with db_unique_name DBIT121_SITE2 are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

There are quite a lot options which can be combined with the DB_UNIQUE_NAME feature like the following.

LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME 'DBIT121_SITE2';
REPORT SCHEMA FOR DB_UNIQUE_NAME 'DBIT121_SITE2';
SHOW ALL FOR DB_UNIQUE_NAME 'DBIT121_SITE2';

But getting back to my issue. I was running a resync catalog from my Standby database and ended up with the following error:

RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME 'DBIT121_SITE1';

resyncing from database with DB_UNIQUE_NAME DBIT121_SITE1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync from db_unique_name command on default channel at 02/21/2017 13:08:42
RMAN-20005: target database name is ambiguous

RMAN says that the target database name is ambiguous. But what does this mean. Let’s take a look a the RMAN error with the oerr utility. The oerr utility can not only be used with “ORA” error codes like “oerr ora 01555”, but also with “RMAN” error codes.

$ oerr rman 20005
20005, 1, "target database name is ambiguous"
// *Cause: two or more databases in the recovery catalog match this name
// *Action:
//

Ok. This error is much more precise. Looks like that RMAN found more the one database called DBIT121 in the catalog, and so RMAN does not know, on which DBID to perform the requested command. Ok. So let’s connect to the RMAN catalog and check if this is really the case.

SQL> SELECT DB.DB_KEY,DB.DB_ID, DB.CURR_DBINC_KEY, DBINC.DB_NAME
        FROM DB, DBINC
       WHERE DB.CURR_DBINC_KEY = DBINC.DBINC_KEY
         AND DBINC.DB_NAME   = 'DBIT121' ;  2    3    4

    DB_KEY      DB_ID CURR_DBINC_KEY DB_NAME
---------- ---------- -------------- --------
         1  642589239              2 DBIT121
    546780  644484523         546781 DBIT121

Indeed. I do have two different DBID’s pointing to the same DB_NAME. Kinda confusing for RMAN. But which one is the one that have been backed up. We could query the RC_BACKUP_SET and RC_BACKUP_PIECE views to find that out.

SQL> SELECT RBS.DB_KEY
         , RD.NAME
         , RBS.DB_ID
  2    3    4           , RBS.BS_KEY
         , RBS.RECID
         , RBS.STAMP
         , RBS.BACKUP_TYPE
         , RBS.START_TIME, STATUS
  5    6    7    8    9        FROM RC_BACKUP_SET RBS, RC_DATABASE RD
     WHERE RBS.DB_KEY=RD.DB_KEY
       AND RBS.DB_ID=RD.DBID
       AND RD.NAME='DBIT121' ;  10   11   12
...
...

    DB_KEY NAME          DB_ID     BS_KEY      RECID      STAMP B START_TIM S
---------- -------- ---------- ---------- ---------- ---------- - --------- -
    546780 DBIT121   644484523     555608       3070  936496831 I 21-FEB-17 A
    546780 DBIT121   644484523     555609       3071  936496832 I 21-FEB-17 A
    546780 DBIT121   644484523     555610       3072  936496836 D 21-FEB-17 A
    546780 DBIT121   644484523     555611       3073  936496860 D 21-FEB-17 A
    546780 DBIT121   644484523     555612       3074  936496875 D 21-FEB-17 A
    546780 DBIT121   644484523     555613       3075  936496884 D 21-FEB-17 A
    546780 DBIT121   644484523     555614       3076  936496890 D 21-FEB-17 A
    546780 DBIT121   644484523     555615       3077  936496895 L 21-FEB-17 A
    546780 DBIT121   644484523     555616       3078  936496897 L 21-FEB-17 A
    546780 DBIT121   644484523     555617       3079  936496897 L 21-FEB-17 A
    546780 DBIT121   644484523     555618       3080  936496898 D 21-FEB-17 A

    DB_KEY NAME          DB_ID     BS_KEY      RECID      STAMP B START_TIM S
---------- -------- ---------- ---------- ---------- ---------- - --------- -
    546780 DBIT121   644484523     555619       3081  936496900 D 21-FEB-17 A
    546780 DBIT121   644484523     555620       3082  936498788 D 21-FEB-17 A
    546780 DBIT121   644484523     555621       3083  936502389 D 21-FEB-17 A
    546780 DBIT121   644484523     555622       3084  936505991 D 21-FEB-17 A
    546780 DBIT121   644484523     555623       3085  936509589 D 21-FEB-17 A
    546780 DBIT121   644484523     555624       3086  936513189 D 21-FEB-17 A
    546780 DBIT121   644484523     555625       3087  936516788 D 21-FEB-17 A
    546780 DBIT121   644484523     555626       3088  936520387 D 21-FEB-17 A
    546780 DBIT121   644484523     555627       3089  936523988 D 21-FEB-17 A
    546780 DBIT121   644484523     555628       3090  936527608 D 21-FEB-17 A
    546780 DBIT121   644484523     555629       3091  936531188 D 21-FEB-17 A
...
...

After checking the output, I see that DBID 644484523 is the correct one, and DBID 642589239 is the one I want to get rid of.

To do so, we can shutdown the Standby database and start it up with nomount. The reason for that, is that you can’t issue the SET DBID command against a database which is mounted or open.

RMAN> SET DBID=642589239;

executing command: SET DBID
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 02/21/2017 13:15:26
RMAN-06188: cannot use command when connected to a mounted target database

Ok. Let’s go the nomount and execute the “unregister database;” command after the correct DBID is set.

$ rman target sys/welcome1 catalog /@rcat

Recovery Manager: Release 12.1.0.2.0 - Production on Tue Feb 21 14:25:10 2017
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DBIT121 (not mounted)
connected to recovery catalog database

RMAN> SET DBID=642589239;

executing command: SET DBID
database name is "DBIT121" and DBID is 642589239

RMAN> unregister database;

database name is "DBIT121" and DBID is 642589239

Do you really want to unregister the database (enter YES or NO)? YES
database unregistered from the recovery catalog

RMAN>

Let’s check the RMAN catalog again.

SQL> SELECT DB.DB_KEY, DB.DB_ID, DB.CURR_DBINC_KEY, DBINC.DB_NAME
        FROM DB, DBINC
       WHERE DB.CURR_DBINC_KEY = DBINC.DBINC_KEY
         AND DBINC.DB_NAME   = 'DBIT121' ;  2    3    4

    DB_KEY      DB_ID CURR_DBINC_KEY DB_NAME
---------- ---------- -------------- --------
    556718  644484523         556719 DBIT121

Cool. Looks much better. 🙂 Now my resync catalog from SITE1 issued from SITE2 works again.

RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

List of Databases
DB Key  DB Name  DB ID            Database Role    Db_unique_name
------- ------- ----------------- ---------------  ------------------
556718  DBIT121  644484523        PRIMARY          DBIT121_SITE1
556718  DBIT121  644484523        STANDBY          DBIT121_SITE2

RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME 'DBIT121_SITE1';

resyncing from database with DB_UNIQUE_NAME DBIT121_SITE1
starting full resync of recovery catalog
full resync complete

Conclusion

The RMAN DB_UNIQUE_NAME persistent setting is a quite cool feature. This is something I would really recommend when working with RMAN and Data Guard. It allows you to do actions on primary from the standby or the standby from the primary. It doesn’t matter. But take care that you don’t have multiple DBID’s pointing to the same DB in your RMAN catalog.