Re: RMAN fails with ORA-00001: unique constraint (RMAN.DF_P) violated
Date: Wed, 4 Mar 2015 09:30:30 -0800
Message-ID: <CALgGkeDGK+M=sbA0mz7p2FAXoktcjupsjLgUN5kpRj+7K8+aBA_at_mail.gmail.com>
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_at_gmail.com> 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_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-lReceived on Wed Mar 04 2015 - 18:30:30 CET