В свое время столкнулся с неприятностью, что проверяя бекап, оптимизатор проверял наличие архивлогов, но не проверял их целостность. В итоге в один прекрасный день сбой контроллера и я остался без архивлогов за полдня.
Попытка проверить архивлоги "в лоб" проваливается в большинстве случаев
SQL код:
RMAN> restore archivelog all validate;
Starting restore at 17:34:36 02.04.2016
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/02/2016 17:34:36
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of archived log for thread 1 with sequence 25 and starting SCN of 10009916 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 24 and starting SCN of 10002861 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 23 and starting SCN of 9910466 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 22 and starting SCN of 9763586 found to restore
я достаточно просто обошел
SQL код:
select 'restore validate archivelog from scn '||min_first_change#||' until scn '||max_next_change# from v$backup_archivelog_summary;
но выяснилось неприятное обстоятельство, что при каких-то условиях (подозреваю установку на 10g redundancy отличным от единицы и delete input) в v$backup_archivelog_summary остается scn, которое бекапу и не снилось. В итоге приехал опять к RMAN-06025 на некоторых БД. Чесал затылок достаточно долго, без металинка плохо (кстати, если кто сможет поделиться учеткой - скажу большое спасибо), пришел к следующему решению
SQL код:
select 'restore validate archivelog from scn '||min(first_change#)||' until scn '||max(next_change#) from v$archived_log where archived='YES' and DELETED='NO';
пока ошибка не возвращается...