Skip to main content

RMAN-06613: Connect identifier for DB_UNIQUE_NAME not configured

I ran into an issue with a recently cloned database. Every time I ran "resync catalog from db_unique_name all;" command in RMAN, it error out with RMAN-6613: connect identifier for db_unique_name not configured.

We know that this command is not needed for non-dg enabled databases, but because we have a mix of DG and non-DG enabled databases, maintaining different scripts per type of database is not worth it. To the extent of my knowledge, this command is harmless; the error is more like a warning on non-dg databases, still is a symptom of something not well configured.

Troubleshooting

Once you connect to the target and catalog repository with RMAN, you try to resync catalog with the following command:


RMAN> resync catalog FROM DB_UNIQUE_NAME ALL;

starting full resync of recovery catalog
full resync complete

resyncing from database with DB_UNIQUE_NAME DBTST
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of resync from db_unique_name command at 07/12/2016 08:17:11
RMAN-06613: Connect identifier for DB_UNIQUE_NAME DBTST not configured
[/code]

This is likely due to a previous incarnation of the database or a clone gone bad of the database. The RMAN Catalog has invalid references to the other database.

So lets see what RMAN is complaining about:

Plain Text>
RMAN> show all for db_unique_name all;

RMAN configuration parameters for database with db_unique_name DBDEV are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
...
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE DB_UNIQUE_NAME 'DBDEV' CONNECT IDENTIFIER  'DBDEV';
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/oracle/product/11.2.0/dbhome_1/dbs/snapcf_dbdev.f'; # default

RMAN configuration parameters for database with db_unique_name DBTST are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
...
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE DB_UNIQUE_NAME 'DBDEV' CONNECT IDENTIFIER  'DBDEV';
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/oracle/product/11.2.0/dbhome_1/dbs/snapcf_dbdev.f'; # default

For some reason, either by an rman bug or another unidentified reason, at some point in time DBDEV was named DBTST (line 12), and RMAN is trying to resync the catalog from that database. We could try to identify which incarnation of the database this is, and see if we can remove that from the catalog without having to unregister the database. For that analysis we can run the following script against the rman catalog database.

SET linesize 150 
COL DB_UNIQUE_NAME FOR a20 
COL RESETLOGS_CHANGE# FOR 999999999999

SELECT DISTINCT db1.db_key,
  db1.db_unique_name,
  db2.db_unique_name
FROM conf db1,
  conf db2
WHERE db1.db_unique_name = 'DBDEV'
AND db2.db_unique_name   = 'DBTST'
AND db1.db_key           = db2.db_key;

SELECT *
FROM rc_database
WHERE db_key =
  (SELECT DISTINCT db1.db_key
  FROM conf db1,
    conf db2
  WHERE db1.db_unique_name = 'DBDEV'
  AND db2.db_unique_name   = 'DBTST'
  AND db1.db_key           = db2.db_key
  );

SELECT * FROM rc_database WHERE name = 'DBDEV' ORDER BY resetlogs_time DESC;

What we are doing with these select statements is identify duplicate values for the same db_unique_name. This is the output for my case:

SELECT DISTINCT db1.db_key,
  db1.db_unique_name,
  db2.db_unique_name
FROM conf db1,
  conf db2
WHERE db1.db_unique_name = 'DBDEV'
AND db2.db_unique_name   = 'DBTST'
AND db1.db_key           = db2.db_key;

DB_KEY DB_UNIQUE_NAME       DB_UNIQUE_NAME     
---------- -------------------- --------------------
  10537415 DBDEV                DBTST              

SELECT *
FROM rc_database
WHERE db_key =
  (SELECT DISTINCT db1.db_key
  FROM conf db1,
    conf db2
  WHERE db1.db_unique_name = 'DBDEV'
  AND db2.db_unique_name   = 'DBTST'
  AND db1.db_key           = db2.db_key
  );

    DB_KEY  DBINC_KEY       DBID NAME     RESETLOGS_CHANGE# RESETLOGS_TIME   
---------- ---------- ---------- -------- ----------------- ------------------
  10537415   10537416 1478582285 DBDEV          3963542354  30-JUN-16 22:15:51

SELECT * FROM rc_database WHERE name = 'DBDEV' ORDER BY resetlogs_time DESC;

    DB_KEY  DBINC_KEY       DBID NAME     RESETLOGS_CHANGE# RESETLOGS_TIME   
---------- ---------- ---------- -------- ----------------- ------------------
  10537415   10537416 1478582285 DBDEV          3963542354  30-JUN-16 22:15:51
   9544640    9544641 1473819989 DBDEV          3331653263  06-MAY-16 19:24:16
   5453380    5453381 1464054891 DBDEV           833388190  17-JAN-16 18:52:45
     79470      79471 1438488533 DBDEV            16631230  31-MAR-15 21:06:34

Solution

In my case the problematic database is the current one, so my only option is to unregister and register the database again. If your problematic database is one of the oldest, then you can use the unregisterdatabase procedure found in dbms_rcvcat package to remove that particular database from the RMAN catalog repository. For example, let’s say we want to remove the database with db_key = 5453380.

SELECT db_key, dbid, resetlogs_time
FROM rc_database
WHERE name = 'DBDEV'
ORDER BY resetlogs_time DESC;

 DB_KEY    DBID       RESETLOGS_TIME 
---------- ---------- ------------------
 10537415  1478582285 30-JUN-16 22:15:51
 9544640   1473819989 06-MAY-16 19:24:16
 5453380   1464054891 17-JAN-16 18:52:45
 79470     1438488533 31-MAR-15 21:06:34

execute dbms_rcvcat.unregisterdatabase(5453380, 146054891);

And with that you should be able to remove the conflicting incarnation of the database.

Hope this help you.

Labels:

Popular posts from this blog

Oracle Linux 7 authentication to Active Directory

Introduction I've been curious from some time to see how Active Directory users could natively authenticate to Linux, or said in a different way, how to configure Linux to allow AD users to log in without the need to have those users in each and every Linux box manually. Although there are several different ways to accomplish this, I found that the easiest and less time consuming way to do it is with the use of Samba WinBind. Later I will show how to use Oracle Internet Directory (OID) to accomplish the same feat. Using an IdM solution (AD, OID) can help to reduce the time to deploy users, you can centrally manage access to linux servers from Active Directory Users and Computers (ADUC) app, and can allow administrative tasks thru sudo depending on the group the users belong to. For my Proof of Concept I created two virtual machines, one with Windows 2012 Server Essentials, and another one with Oracle Linux 7.1. In AD I created 1 group named osd-linux-oretail, and several tes
3 comments
Read more

Fixed Objects and Data Dictionary Statistics

I Recently came across a performance issue in a 12c database. Queries that used to run in 500 ms, now were taking several minutes to complete, in some cases 30 or more minutes. While troubleshooting the issue, many different ideas came to mind to try to resolve the issue - gather schema stats, change optimizer settings, partition related objects, etc. After trying all these options - and some more, we were able to improve response time; now it was consistently around 5 seconds, but still way too far from the 500 ms that was before. While analysing the (still) issue, I realized that when getting an explain plan for the queries, it would take around 5 seconds to get it. So I decided to gather stats on fixed objects and on data dictionary in order to improve explain plan response time. After having done this, overall system performance improved considerably, explain plan response time came down to couple milliseconds, and problematic queries returned to normality, ~500ms. Obviously this i
2 comments
Read more

RMAN 12c - SBT vs TAPE

I recently upgraded a database from 11g to 12c without issues, but after several days, I noticed that the archived redo logs were not being deleted from the filesystem, even after they were backed up to tape. At first I thought that there might be some issues with that specific database, but when I verified other 12c databases that uses the same backup script, I found that they were exhibiting the same behaviour. So I started the troubleshooting process by checking the RMAN configuration, nothing seemed out of the ordinary. I use the following settings: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO TAPE; CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 4 BACKUP TYPE TO BACKUPSET; CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE BACKUP OPTIMIZATION OFF; The RMAN command is this: run { backup filesperset 1 tag ‘arl_test’ archivelog all; d
2 comments
Read more