vis, May 22, 2018 - 6:27 am UTC
Thank you... :) now iam in the right track!!
Kevin, September 29, 2020 - 1:23 pm UTC
The problem with this is that if you have a true problem (ie, an archivelog is missing and was not backed up), then once you run crosscheck - you have just told RMAN that this archive no longer exists and if it was never backed up - then you have big recovery dramas. Let RMAN do the deletion and run crosscheck as a means of confirming that RMAN is *always* in sync, rather then *getting* RMAN in sync.
I currently am in this situation and do not know how to recover?? I am trying to duplicate the production database to the test environment on the same server. it fails looking for the deleted archivelog files.... I have done a "new" backup that includes my current archivelogs, set my backup retention policies to 1 day. I have crosschecked and deleted expired. cataloged... etc.
September 30, 2020 - 2:26 am UTC
If you do "duplicate from active database" then the process should take care of getting all the archive logs that are required.
Kevin, September 30, 2020 - 2:46 pm UTC
I have tried duplicate from active database as well and also crosschecked backups and copys... no luck. whits end.
October 01, 2020 - 1:06 am UTC
If "duplicate from active database" didn't work, then this is not a missing archive problem because we don't look for old backups - we take a new one.
Shows us the entire output from your duplicate.
Kevin, October 01, 2020 - 8:16 pm UTC
Ok, I started completely from scratch in order to get the log files fresh. new backup, new delete obsolete, tried copying from backups with no luck. then tried "DUPLICATE FROM ACTIVE DATABASE" and it worked. not sure what the difference was. I have bounced and had a snap file issue corrected since the last time I tried it... so unless I made a mistake during my process I can't really tell why it did work this time.
here is the output from the failed duplicate from backup too much to paste, cant upload the file so I added a link to google drives, hopefully that works.
https://drive.google.com/file/d/1iuhBP07Ub0ltEq_BcnR55PRA0Um7dj7g/view?usp=sharing
October 02, 2020 - 2:12 am UTC
RMAN duplicate by default always tries to "resume" from a failed one. See in the logs you have this:
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\SYSTEM01.DBF for datafile 1 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\SYSAUX01.DBF for datafile 2 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\UNDOTBS01.DBF for datafile 3 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\USERS01.DBF for datafile 4 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\IMPDATA01.DBF for datafile 5 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\IMPINDEX01.DBF for datafile 6 with checkpoint SCN of 1554002103
Using previous duplicated file E:\APP\ADMINISTRATOR\ORADATA\SAND\REPORTRAKTS.DBF for datafile 7 with checkpoint SCN of 1554002103
so even though you ran a fresh duplicate command, we're using old datafiles from a previous duplicate/restore/etc.
Delete those and see how you go