You say 2 days of backups - Do you run another script against this database during the week that
also has a "delete obsolete" in it? A duplicate database or "refresh" script
perhaps?
Cheers,
Tony
On 08/10/15 09:55, Woody McKay wrote:
Hi Andrew,
This is a script I've inherited and won't be able to change till next spring -
and I do appreciate any improvements. However, this script has been working
fine in thousands of servers for several years. I'm thinking there must be
something about this particular server.
Even though the "restore archivelog validate" is asking for the last 2 weeks,
shouldn't it be able to run successfully even if there are only 2 days of backups?
Am I misunderstanding or missing something?
Thanks
On Wed, Oct 7, 2015 at 7:43 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx
<mailto:andrew.kerber@xxxxxxxxx>> wrote:
I'm not sure I understand the problem. Everything seems to be working
properly. You have a recovery window of 7 days and are asking for archive logs
14 days old, and they are gone as they should be. I don't actually see a
problem here.
Sent from my iPad
On Oct 7, 2015, at 6:27 PM, Woody McKay <woody.mckay@xxxxxxxxx
<mailto:woody.mckay@xxxxxxxxx>> wrote:
Hi, ( note, cross posted in Oracle community Database Backup and Recovery )
I'm not super-versed with RMAN but am trying to resolve an rman issue on a
development server. The DB environment can be rebuilt if needed, but I'd like
to try and resolve this with a crosscheck command, etc.
The weekly rman backup script looks like:
run {
configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to '%F';
configure retention policy to recovery window of 7 days;
allocate channel d1 type disk maxpiecesize=5G;
backup as compressed backupset incremental level 0 cumulative tag
'L0'database
plus archivelog delete all input;
restore database validate;
release channel d1;
delete noprompt obsolete;
restore database check logical validate;
backup validate database;
*restore archivelog from time 'SYSDATE-14' validate;*
host 'copy C:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\tnsnames.ora
C:\oradata\fast_recovery_area\';
host 'copy C:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\sqlnet.ora
C:\oradata\fast_recovery_area\';
host 'copy C:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\listener.ora
C:\oradata\fast_recovery_area\';
host 'copy C:\oracle\product\12.1.0\dbhome_1\database\pwd*.ora
C:\oradata\fast_recovery_area\';
}
list incarnation of database;
list backup summary;
list backup by file;
list recoverable backup of database;
report schema;
report need backup redundancy=3;
report need backup recovery window of 3 days;
The command "restore archivelog from time 'SYSDATE-14' validate;" is
throwing the below error:
RMAN> restore archivelog from time 'SYSDATE-14' validate;
Starting restore at 07-OCT-15
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/07/2015 15:15:49
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of archived log for thread 1 with sequence 38 and
starting SCN of 4330735 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 37 and
starting SCN of 4324802 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 36 and
starting SCN of 4311903 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 35 and
starting SCN of 4230358 found to restore
...
Note, that "RMAN> restore archivelog from time 'SYSDATE-1' validate;" does
work successfully.
I did find and removed on obsolete backup set, but that didn't resolve the
06026 error.
I tried "crosscheck archivelog all;", but that does not resolve the 06026
error during the restore archivelog validate.
Is there a crosscheck command or other command that would sync the catalog
and disk to resolve the 06026?
Thanks for all replies.
-- Sincerely,
WoodyMcKay
--
Sincerely,
WoodyMcKay
