Как узнать все ли архивные логи есть для recovery?

YAP
Дата: 02.08.2005 18:14:48
Oracle 9.2.0.4/Linux

Исходная ситуация
RMAN> list backup;

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
1       739M       DISK        00:00:42     02-AUG-05
        BP Key: 1   Status: AVAILABLE   Tag: TAG20050802T163918
        Piece Name: /disk4/oradata/rman/spo01/01gr3827_1_1

  List of Archived Logs in backup set 1
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    1       423215514  02-AUG-05 423262353  02-AUG-05
...
  1    8       423748348  02-AUG-05 423841759  02-AUG-05

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2       Full    1G         DISK        00:00:37     02-AUG-05
        BP Key: 2   Status: AVAILABLE   Tag: TAG20050802T164005
        Piece Name: /disk4/oradata/rman/spo01/02gr383m_1_1
  List of Datafiles in backup set 2
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 423841817  02-AUG-05 /disk2/oradata/spo01/system01.dbf
...
  121     Full 423841817  02-AUG-05 /disk3/oradata/spo01/UNDOTBS4.dbf

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
3       37K        DISK        00:00:01     02-AUG-05
        BP Key: 3   Status: AVAILABLE   Tag: TAG20050802T164051
        Piece Name: /disk4/oradata/rman/spo01/03gr3854_1_1

  List of Archived Logs in backup set 3
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    9       423841759  02-AUG-05 423841869  02-AUG-05

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4       Full    3M         DISK        00:00:01     02-AUG-05
        BP Key: 4   Status: AVAILABLE   Tag:
        Piece Name: /disk4/oradata/rman/spo01/c-2584450430-20050802-00
  SPFILE Included: Modification time: 02-AUG-05

RMAN> list copy;

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
10      1    10      A 02-AUG-05 /disk4/oradata/spo01/archive/1_10.log
11      1    11      A 02-AUG-05 /disk4/oradata/spo01/archive/1_11.log
12      1    12      A 02-AUG-05 /disk4/oradata/spo01/archive/1_12.log
13      1    13      A 02-AUG-05 /disk4/oradata/spo01/archive/1_13.log

Предположим файл /disk4/oradata/spo01/archive/1_11.log случайно удален и физически и из репозитария rman (например: удалили файл, затем crosscheck и delete expired).

Есть ли способ узнать что некоторого архивного лога не хватает для успешного исполнения команды подобной
recover database until sequence 14 thread 1

до запуска такой команды?
Oracle newbie
Дата: 02.08.2005 18:20:11
запускай
restore...validate

Regards.
YAP
Дата: 02.08.2005 18:34:31
Oracle newbie
запускай
restore...validate


Запускал конечно же!
Никак не реагирует на отсутствие архивного лога.
Причем пробовал как просто удалять файл, так делать crosscheck, и в конце концов delete expired. Никаких сообщений :(
YAP
Дата: 04.08.2005 15:57:00
Неужели никто не озадачивался таким вопросом?
val-demar
Дата: 04.08.2005 17:12:04
RECOVER ... TEST 
?
YAP
Дата: 04.08.2005 19:14:30
Кажется мне что это из другой оперы...
val-demar
RECOVER ... TEST
Александр Соколов
Дата: 04.08.2005 19:32:36
Oracle
Оператор SQL*Plus RECOVER ... TEST может выполнить пробное восстановление в оперативной памяти не затрагивая физическую базу данных. Эта возможность позволяет проводить тестирование методов резервирования и восстановления без фактического внесения изменений в файлы. Кроме того, при проведении диагностики и исправлении ошибок пробное резервирование позволяет предусмотреть проблемы, которые могут возникнуть, если продолжить восстановление в обычном режиме.
...
По умолчанию пробное восстановление всегда пытается повредить блоки в памяти, если это не препятствует его продолжению. Другими словами, пробное восстановление может повредить неограниченное количество блоков данных. Можно указать инструкцию ALLOW n CORRUPTION в операторе RECOVER ... TEST, чтобы ограничить количество повреждаемых блоков данных.
мфд-вуьфк
Дата: 04.08.2005 20:23:31
Александр Соколов
Oracle

По умолчанию пробное восстановление всегда пытается повредить блоки в памяти, если это не препятствует его продолжению.


Для чего он их повреждает ?
MacDuck
Дата: 04.08.2005 20:31:54
YAP

Предположим файл /disk4/oradata/spo01/archive/1_11.log случайно удален и физически и из репозитария rman (например: удалили файл, затем crosscheck и delete expired).


А из destination сносишь?
И покажи-ка что пишет crosscheck. Как вызываешь и что пишет RMAN.
YAP
Дата: 04.08.2005 23:54:07
Я проводил эксперимент следующим образом:
1. Сделал бекап.
2. Сгенерил логов несколько штук.
3. Удалил один архивный лог, котороый появился после бекапа.
4. Запустил команду restore ... validate
5. Сделал crosscheck copy, удаленный архивный лог пометился как expired
6. Повторил шаг 4.
7. Сделал delete expired copy.
8. Снова повторил шаг 4.

Во всех случаях вывод команды restore ... validate ни чем не примечателен, и ничем не отличается от вывода этой команды когда все на месте: выделение канала, упоминание существующего файла бекапа, и т. д.
С Вашего позволения, завтра приведу точный листинг.