Re: RMAN fails with ORA-00001: unique constraint (RMAN.DF_P) violated
- From: pavan kumar <pavan_843@xxxxxxxxxxx>
- To: "richa03@xxxxxxxxx" <richa03@xxxxxxxxx>, Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 5 Mar 2015 02:53:04 +0000 (UTC)
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@xxxxxxxxx>
To: Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
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
Other related posts:
