Восстановление после потери оперативных журналов повторного выполнения

dbstalker, 18 июня

Этот вопрос немного освещен в посте и в этом. А здесь изложен вольный почти перевод :) оракловской документации.

Если в результате сбоя носителя пострадали оперативные журнальные файлы базы данных, процедура восстановления зависит от следующих факторов:

  • Журналы мультиплексированы?
  • Проблемы с носителе временные или неисправимые?
  • Какой статус у журнала на сбойном носителе: current, active, unarchived, or inactive?

Посмотрите в представление V$LOG, и вы получите следующую информацию.

UNUSED.В этот журнал никогда оракл не записывал.

CURRENT. Этот журнал активный, а значит, необходим для восстановления. В данный момент оракл в него пишет. Этот журнал может быть open или closed.

ACTIVE. Этот журнал активный, а значит, необходим для восстановления. Но в этот журнал оракл в данный момент не пишет. Возможно, в данный момент используется для восстановления блоков. Может быть как заархивированным, так и незаархивированным.

CLEARING. Этот журнал создается повторно и очищается командой ALTER DATABASE CLEAR LOGFILE. Затем он перейдет в статус UNUSED.

CLEARING_CURRENT. Текущий журнал очищается закрытым потоком. Журнал может быть в этом статусе, если при переключении произойдет сбой (например, ошибка ввода-вывода при записи нового заголовка журнала).

INACTIVE. Журнал уже не нужен для восстановления экземпляра, но возможно будет использован при восстановлении носителя. Может быть как заархивированным, так и незаархивированным.

Далее описываются стратегии восстановления для двух ситуаций.

Восстановление после потери элемента мультиплексированной Online Redo Log Group

Если online redo log вашей базы данных мультиплексированы и если хотя бы один элемент каждой online redo log group не поврежден по причине сбоя носителя, тогда база данных продолжит работу в обычном режиме. Oracle выдаст ошибку в файл трассировки для LGWR и в alert_SID.log базы данных.

Решить проблему можно следующими действиями:

Если проблема с носителем временная и удалось ее решить, то когда LGWR получит доступ к ранее недоступным оперативным журналам и будет проводить в него запись как будто проблемы и не было сбоя.

Если носитель утрачен навсегда, тогда нужно удалить поврежденный элемент и добавить новый элемент (новый элемент не обеспечит сразу мультеплексирования, а только при повторном использовании этой группы), используя следующую процедуру:

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE WHERE STATUS='INVALID';

GROUP#    STATUS       MEMBER
-------   -----------  ---------------------
0002      INVALID       /oracle/dbs/log2b.f

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log2b.f';

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.f' TO GROUP 2;
Или если файл существует и имеет такой же размер как и другие элементы:
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.f' REUSE TO GROUP 2;

Восстановление после потери всех элементом Online Redo Log Group

Если сбой носителя привел к повреждению всех элементов оперативной журнальной группы, тогда есть ряд сценариев в зависимости от статуса журнала и в каком режиме работала база данных (Archivelog или Noarchivelog)

Если группа имеет статус Inactive, тогда она не нужна для восстановления после сбоя, и можно очистить заархивированную или незархивированную группу.

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

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

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

GROUP#    STATUS       MEMBER
-------   -----------  ---------------------
0001            		    /oracle/dbs/log1a.f
0001            		    /oracle/dbs/log1b.f
0002      INVALID         /oracle/dbs/log2a.f
0002      INVALID        /oracle/dbs/log2b.f
0003                              /oracle/dbs/log3a.f
0003                              /oracle/dbs/log3b.f

SELECT GROUP#, MEMBERS, STATUS, ARCHIVED FROM V$LOG;

GROUP#  MEMBERS           STATUS     ARCHIVED
------          -------                     ---------        -----------
 0001        2                             INACTIVE   YES
 0002        2                             ACTIVE        NO
 0003        2                             CURRENT    NO

Потеря Inactive Online Redo Log Group

Если все элементы redo log group, которая в статусе INACTIVE повреждены, то процедура зависит от какой (постоянный или временный) сбой носителя, где был потерян журнал.

Если временный сбой, тогда решите проблему носителя. После этого LGWR будет использовать эту журнальную группу.

Если проблема постоянна, тогда повреждение журнала приведет к остановке нормальной роботы базы данных. Инициализируем журнальную группу используя ALTER DATABASE CLEAR LOGFILE .

Очистка журнала в статусе inactive, которые уже заархивированы:

Если база остановлена, то сначала стартуем и монтируем

STARTUP MOUNT
Инициализируем поврежденную группу. 
ALTER DATABASE CLEAR LOGFILE GROUP 2;

Очистка журнала в статусе inactive, которые не заархивированы:

Очистка незаархивированного журнала позволит его использовать без архивирования. Эта операция делает его резервные копии непригодными. То есть восстановление невозможно будет из-за отсутствия журнального файла.

STARTUP MOUNT
ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2;
Или, 
если существует автономный файл данных, для перевода которого в оперативный режим требуется очищенный незаархированный журнальный файл ( потом файл данных и табличное пространство нужно удалить из базы данных):

ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2 UNRECOVERABLE DATAFILE;

После всего этого нужно позаботиться о резервной копии базы данных.

Команда ALTER DATABASE CLEAR LOGFILE может быть завершена ошибкой ввода-вывода из-за того, что вследствие сбоя носителя невозможно:

  • Переместить журнальный файл на другой носитель путем повторного создания файла с текущим именем;
  • Повторно использовать текущее имя для создания журнального файла , из-за того, что само имя некорректно или не пригодно к использованию ( например, из-за сбоя носителя).

В этих случаях оператор ALTER DATABASE CLEAR LOGFILE сначала занесет в управляющий файл информацию о том , что журнал был успешно очищен и не требует архивирования, а только потом будет получено сообщение об ошибке ввода-вывода. Ошибка ввода-вывода возникает , когда оператор CLEAR LOGFILE пытается создать новый журнальный файл и обнулить его. Это все видно в представлении V$LOG.CLEARING_CURRENT.

Потеря активной оперативной журнальной группы

Если база данных еще работает и потерянный активный журнальный файл не является текущим, выполните ALTER SYSTEM CHECKPOINT. Если выполнение завершится успешно, тогда журнальный файл становиться неактивным и тогда выполняем процедуру, изложенную выше для неактивных журнальных групп. Иначе выполните одну из следующих процедур, в зависимости от режима архивирования.

Внимание! Если возникли проблемы с ТЕКУЩИМ журнальным файлом (именно в него процесс LGWR ведет текущую запись), и LGWR не может выполнить в него запись из-за ошибки ввода-вывода, тогда происходит сбой экземпляра. Вам необходимо восстановить резервную копию и выполнить неполное восстановление. База отрываться в этом случае должна с параметром RESETLOGS.

Для восстановления при потере активной оперативной журнальной группы в режиме NOARCHIVELOG необходимо выполнить следующий сценарий:

Восстановите базу данных из согласованной резервной копии и выполните восстановление базы данных: 
STARTUP MOUNT

RECOVER DATABASE UNTIL CANCEL
CANCEL

ALTER DATABASE OPEN RESETLOGS;

SHUTDOWN IMMEDIATE

Сразу же сделайте полную резервную копии базы данных.

Для восстановления при потере активной оперативной журнальной группы в режиме ARCHIVELOG необходимо выполнить следующий сценарий:

Необходимо выполнить неполное восстановление. Восстановите резервную копию и примените все журнальные записи, предшествующие поврежденному файлу.

В случае необходимости переместите элементы поврежденной оперативной журнальной группы в новое место:

ALTER DATABASE RENAME FILE "/oracle/dbs/log_1.rdo" TO "/temp/log_1.rdo";
ALTER DATABASE RENAME FILE "/oracle/dbs/log_2.rdo" TO "/temp/log_2.rdo";

Базу данных откройте с параметром RESETLOGS

ALTER DATABASE OPEN RESETLOGS;

Выполните полное резервное копирование.

Потеря нескольких Redo Log Groups

Если потеряны несколько оперативных журналов, тогда нужно строит сценарий восстановления на основе метода наиболее подходящего к самому сложному журнальному файлу. Порядок файлов по сложности:

current online redo log
active online redo log
unarchived online redo log
inactive online redo log

Если утрачены архивные журнальные файлы, то выход может быть только один – полное резервирование базы. Иначе в случае сбоя носителя вы не сможете восстановить базу данных на текущее время.

1 комментарий

Прокоментировать

Roman
16 марта 2010 г. в 11:21

Полезная информация ))

 

Новый комментарий

Я не спамер: введите суму 3+2



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Телепрограмма
23 июня, 1 ответа
Турция
23 июня, 4 ответа
Выбор люстры
22 июня, 1 ответа