It also looks like either the nid procedure was not executed correctly - correcting that now and getting new level 0 backups. select DBID, NAME from v$database; Result for each instance: DBID NAME ---------- --------- 3201590206 D724DB1 3176421570 D724DB2 3176421570 D724DB3 3176421570 D724DB4 I think this (correct execution of nid and new backups) should solve it... On Wed, Mar 4, 2015 at 9:07 AM, Rich <richa03@xxxxxxxxx> wrote: > We are using an rman catalog. > > Looking closer at it, I see for this DB_NAME, we have 3 DB_UNIQUE_NAMEs: > select DB_NAME, DB_KEY, DBINC_KEY, DB_UNIQUE_NAME, count(*) from > RMAN.RC_DATAFILE where DB_NAME like 'D724%' group by DB_NAME, DB_KEY, > DBINC_KEY, DB_UNIQUE_NAME order by 1, 2, 3; > DB_NAME DB_KEY DBINC_KEY DB_UNIQU COUNT(*) > -------- ---------- ---------- -------- ---------- > D724DB3 16975703 16975704 D724DB2 85 > D724DB3 16975703 16975704 D724DB3 85 > D724DB3 16975703 16975704 D724DB4 85 > > Appears two other instances were created via VMWare cloning. The DBID and > database name were changed with nid (using the procedure at > http://docs.oracle.com/cd/B28359_01/server.111/b28319/dbnewid.htm#i1004683 > ). > > Now, the question is why does RMAN think they are the same DB_NAME? > The parameter DB_NAME on these other instances is set correctly... > > > On Wed, Mar 4, 2015 at 8:47 AM, John Smith <john40855@xxxxxxxxx> wrote: > >> Are you using an rman catalog? If so, you might consider dropping and >> re-creating it. >> >> On Wed, Mar 4, 2015 at 9:48 AM, Rich <richa03@xxxxxxxxx> wrote: >> >>> Hi List, >>> This is 11.1.0.7 on RHEL 5.1 (external application requirements). >>> >>> I don't know if this is related, however, this started with only >>> incremental backups failing with: >>> ORA-19643: datafile 6: incremental-start SCN is too recent >>> ORA-19640: datafile checkpoint is SCN 656412919 time 02/27/2015 06:46:55 >>> (sometimes datafile 83 and different SCN numbers) >>> >>> Fulls were OK until just recently; they now fail with: >>> ORA-00001: unique constraint (RMAN.DF_P) violated >>> >>> No changes to backup scripts which are fairly standard - the logfile and >>> error stack (for a full) is: >>> RMAN> run { >>> 2> show all; >>> 3> backup incremental level = 0 database plus archivelog delete >>> input tag Full_DB_20150304_062126 ; >>> 4> delete noprompt force obsolete ; >>> 5> } >>> starting full resync of recovery catalog >>> RMAN-00571: =========================================================== >>> RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== >>> RMAN-00571: =========================================================== >>> RMAN-03002: failure of show command at 03/04/2015 06:21:31 >>> RMAN-03014: implicit resync of recovery catalog failed >>> RMAN-03009: failure of full resync command on default channel at >>> 03/04/2015 06:21:31 >>> ORA-00001: unique constraint (RMAN.DF_P) violated >>> >>> Google and MOS have been little to no help...did find Bug 9288598, >>> however, this is not a standby and I don't think it ever was. >>> Support is also "working" on this, however, not much there either (just >>> sent them log files and a debug). >>> >>> We do see that these datafiles (6 & 83) as well as some others have >>> UNRECOVERABLE_CHANGE# populated and UNRECOVERABLE_TIME with a date back in >>> 2013. This looks to me like there was some NOLOGGING activity back then, >>> but I don't think this should be an issue? >>> >>> Any ideas? >>> >>> Thanks, >>> Rich >>> >> >> >