Падение базы : Oracle

Уж сколько раз твердили миру, следите за бекапами. Проверяйте их утилитой dbv, даже то, тчо она у вас открылась на другом компе не дает 100% гарантии восстановления.
Что касается непосредственного падения, первое что делаете - бэкап того, что осталось.
Второе - заходите в svrmgrl (8i) или sqplus /nolog (9i), в первом случае, как internal, во втором - sys as sysdba, в техподдержку нужно отсылать сообщения оттуда, а не зябликов из DBA Studio или EMC. Если упало по media recovery, то пишете одну добрую команду recover. Тут остаетесь либо с нормальной базой, либо с необходимостью добежать до ближайшего бэкапа. Самое частое убийство базы - падение с повреждением текущего redo, это смерть. Но 40% - recover спасает. Только обязательно dbv прогнать потом.
Далее - градации, INDEX - восстановить можно, но дорого, SYSTEM - морг, USERS - 85% - морг.
*53

Кстати, желающим избежать полной потери базы, настоятельно рекомендую ознакомиться с режимом archivelog и замечательной вещью RMAN. Особенно на 9i и выше. Репозиторий можно делать в каталоге, все супер. Но учтите, что сам режим вам никто расписывать не будет, по вполне понятной причине, либо вы с мозгами и делаете это все сами, либо без мозгов и тогда поддерживать этот режим не сможете.
Мануалы и еще раз мануалы, *123
Я когда с RMANом играл, базу случайно удалил, так вот одной командой ее вернул на место. Это к теме о его возможностях. Причем сбойные блоки он тоже лечит. Что в случае с холодным бэкапом смертельно.

Причины по которым могут появляться сбойные блоки в табличном пространстве в подавляющем своем большинстве связаны с аппаратным обеспечением, т.е. с "железом". Теоретически есть вероятность, что блок может быть поврежден в результате какой-то программной ошибки в Oracle или ОС, как первого рубежа при записи данных на диск, но учитывая масштабы тестирования и время работы, эти ошибки уже неоднократно бы вызывали скандалы и были исправлены. Поэтому, в случае, когда обнаруживаются сбойные блоки, я бы предложил перебрать следующие варианты:
1) Неожиданные выключения питания
2) Сбой дисков
3) Сбой контроллеров ввода/вывода
4) Сбой памяти

А чем проверять бэкапы, если размер файлов больше 2 ГБ?

RMAN рулит :) на самом деле делайте exp базы и будет вам счастье... Это и просто и надежно.

Вот,вдогонку... Кстати, с exp есть вариант нарваться на битый индекс...
Есть три способа проверки файлов на наличие порченых блоков:
1. Утилита DBVERIFY (ограничение на размер datafile - 2Gb ?). Справку по параметрам можно получить так:
C:\> dbv help=y
Обязательно указывайте размер блока (BLOCKSIZE)

2. Команды
a) ANALYZE TABLE ... VALIDATE STRUCTURE [CASCADE];
Дополнительная опция CASCADE проверяет также все индексы и их корректность, т.е. что индекс указывает на правильный блок. Правда, при этом таблица заблокирована для модификаций. Это самый полный метод проверки, но и самый "дорогой".
b) ANALYZE INDEX ... VALIDATE STRUCTURE;

3. Утилита RMAN - наиболее предпочтительный метод проверки, хотя и не так полон по сравнению с 2a) CASCADE. Можно одновременно выполнить и резервирование БД. Если нужна только проверка, то в команде RMAN'а COPY или BACKUP можно указать опцию VALIDATE (бэкап создаваться не будет), а также дополнительно включить проверку логической структуры блока - CHECK LOGICAL.
Кроме того, в отличие от первых двух методов, можно ограничить потребление ресурсов утилитой RMAN, например, чтобы не мешать нормальной работе пользователей. Для этого следует указать ограничение для канала (ALLOCATE CHANNEL ... RATE = x). Пример:
C:> RMAN @X.RMN
============================== X.RMN ==============================
CONNECT TARGET / RUN {
ALLOCATE CHANNEL c1 TYPE DISK RATE=512K;
BACKUP CHANNEL c1 VALIDATE CHECK LOGICAL DATABASE; }; EXIT;
===================================================================

Для проверки файла данных #1 без ограничений на загрузку диска ============================== X1.RMN ==============================
CONNECT TARGET / RUN {
ALLOCATE CHANNEL c1 TYPE DISK;
BACKUP CHANNEL c1 VALIDATE CHECK LOGICAL (DATAFILE 1); }; EXIT;
=======================================================

ПАМАГИТЕ...
возможно вопрос замыленный но всеже...
после бакапа методом копирования файлов БД, база перестала подниматься, а только переходила в mounted, ругаясь 01110 и 01113
на файл RBS01.dbf
начитавшись начала ветки я сделал recovery и попатался проверить все dbv.exe.
но на эти файлы утилита обругалась что при чтерии происходит ошибка I/O. на третий файл сказала что все ОК...
но после восстановления база поднялась и СМ заработал...
что делать?

Не понятно как-то. Лучше бы во-первых ошибки полностью приводить, лазить за расшифровкой напрягает. Во-вторых лучше на каждый такой случай новую тему заводить. Теперь по теме:
ошибки по I/O могут происходить, если файлы больше или равны 2Гб. Не понятно, зачем что-то делать, если после recover все заработало... Но хорошо бы прогнать оптимайзер с проверкой структуры.

ORA-01113: file n needs media recovery
ORA-01110: data file n: '<full file name>'
это они *01
т.е. это ограничение dbv.exe значится...
а может лучше использовать бакап через иморт/экспорт?
Оракл 8.1.6...

А имя файла какое? RBS ? пересоздай его...