Re: RMAN fails with ORA-00001: unique constraint (RMAN.DF_P) violated

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_at_gmail.com> 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_at_gmail.com> 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
>>
>
>

--
http://www.freelists.org/webpage/oracle-l