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

From: John Smith <john40855_at_gmail.com>
Date: Wed, 4 Mar 2015 10:47:00 -0600
Message-ID: <CALh2Jyu6ttKrYOSZfYzA97wcFApe9Q6B9O-C2Fm8uTf4LtQ16w_at_mail.gmail.com>

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

Received on Wed Mar 04 2015 - 17:47:00 CET