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.