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

From: pavan kumar <pavan_843_at_yahoo.co.in>
Date: Thu, 05 Mar 2015 02:53:04 +0000
Message-ID: <667866635.2031645.1425523984447.JavaMail.yahoo_at_mail.yahoo.com>

Hi,
1. Can you able to find RMAN.DF_P constraints details from catalog db 2. Secondly, check/once again try why that record is failing, if it's too old record in catalog table, you may delete that record from catalog table/segment and re-try - ThanksPavan kumar N

      From: Rich <richa03_at_gmail.com>
 To: Oracle-L Freelists <oracle-l_at_freelists.org>  Sent: Wednesday, 4 March 2015 9:18 PM
 Subject: RMAN fails with ORA-00001: unique constraint (RMAN.DF_P) violated    

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 Thu Mar 05 2015 - 03:53:04 CET