Неполное восстановление БД по времени и по номеру системных изменений SCN. Неполное восстановление БД по времени и по номеру системных изменений SCN

Восстановление до прерывания (по номеру системных изменений SCN)

Этот метод восстановления завершает свою работу, когда в командной строке восстановления вводится CANCEL (вместо имени журнального файла). Этот подход используется в следующих ситуациях:

Текущий журнальный файл либо журнальная группа повреждены и недоступны для восстановления. Зеркалирование, как правило, предотвращает потребность в таком типе восстановления.

Архивный журнал, требующийся для восстановления, потерян. Частое резервирование и дублирование архивов должны предотвратить потребность в таком виде восстановления.

Восстановление по номеру изменения

Восстановление согласно этому методу прекращается после того, как в базе данных зафиксированы все изменения, внесенные до указанного системного номера изменения (SCN). Данный подход используется при восстановлении баз данных, работающих в распределенной среде.

Шаги по неполному восстановлению, управляемому пользователем

1.Полное резервирование существующей закрытой базы данных. Перед началом восстановления необходимо завершить работу базы данных, поскольку восстановление всех файлов данных будет выполняться из предыдущей резервной копии.

2.Восстановление из резервной копии всех файлов данных приведет к откату базы данных назад во времени.

3.Затем нужно запустить базу данных в режиме монтирования и удостовериться в том, что файлы данных в оперативном режиме.

4.Выполнить восстановление базы данных.

5.Открыть базу данных при помощи опции RESETLOGS и проверить результаты восстановления.

6.Выполнить полное резервирование закрытой базы данных.

Пример неполного восстановления с использованием предложения until time (по вермени):

Остановите базу данных и приступите к восстановлению. Поскольку известно приблизительное время сбоя и структура базы данных с 11:44 утра не изменялась, можно использовать метод восстановления по времени (UNTIL TIME):

1. Если база данных открыта, то нужно завершить ее работу.

2. Восстановите все файлы данных из резервной копии (самой последней, если это возможно).

3. Смонтируйте базу данных.

4. Восстановите базу данных:

SQL> RECOVER DATABASE UNTIL TIME '2001-03-09:11:44:00';

5. Для синхронизации файлов данных с управляющими и журнальными файлами необходимо открыть базу данных с использованием параметра RESETLOGS:

SQL> ALTER DATABASE OPEN RESETLOGS;

SQL> ARCHIVE LOG LIST;

6. Перед выполнением полного резервирования необходимо выполнить запрос к таблице EMPLOYEES для того, чтобы убедиться в ее наличии. Если восстановление завершилось успешно и резервирование выполнено, можно уведомить пользователей, что база данных доступна для использования, а все данные, введенные после времени, на которое выполнено восстановление (утро, 11:44), должны быть введены повторно.

Пример неполного восстановления с использованием предложения until cancel (по номеру системных изменений SCN):

Необходимо решить проблемы, вызванные повреждением блока в таблице EMPLOYEES из-за сбоя диска. Поскольку журналы хранятся на том же диске, проверяется состояние оперативных и архивных журналов:

SQL> SELECT * FROM V$LOGFILE;

GROUP#       STATUS             MEMBER

2                                               /diskl/data/log2a.rdo

1                                               /diskl/data/logla.rdo

SQL>SELECT * FROM V$LOG;

G# ... SEQ# BYTES MEMBERS ARC    STATUS   ... FIRST_TIME

1 ... 49     153600    1                  NO     CURRENT ... 01-03-09:11:55

2 ... 48     153600    1                  NO     INACTIVE ... 01-03-09:11:34

После поиска в директории /diskl/data было обнаружено, что журнал 1оg2а.rdo отсутствует и не был записан в архив. Поэтому невозможно продолжить восстановление, начиная с этого журнала.

Результат запроса V$LOG_HISTORY подтверждает отсутствие архивного журнала номер

48 (log2a.rdo):

SQL> SELECT * FROM V$LOG_HISTORY;

RECID   STAMP         ...  FIRST_CHANGE     FIRST_TIME

1         318531466     ...  88330                        01-02-28:12:43

47       319512880     ... 309067                       01-03-09:11:26

Поскольку рассматриваемая система является OLTP-системой, результат запроса V$LOG показывает, что при восстановлении базы данных до момента применения log2a.rdo будет потерян результат работы в течение 10 минут. Пользователям придется повторно ввести данные. Поэтому необходимо начать восстановление базы данных из резервной копии.

1.Сначала завершается работа базы данных.

2.Выполняется восстановление всех файлов данных из самой последней резервной копии.

3.Поскольку корректная резервная копия уже существует, то монтируется база данных.

4.Выполняется восстановление базы данных до номера журнала 48:

SQL> RECOVER DATABASE UNTIL CANCEL;

ORA-00279:change 148448...03/02/0112:45:20 needed for thread

ORA-00289: suggestion : /diskl/archive/arch_34.rdo

ORA-00280: change 148448 for thread 1 is in sequence #34

Log applied.

…

ORA-00279:change 309012...03/09/0111:33:56 needed for thread

ORA-00289: suggestion : /diskl/archive/arch_48.rdo

ORA-00280: change 309012 for thread 1 is in sequence #48

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

cancel

Media recovery cancelled.

5.База данных открывается с параметром RESETLOGS.

6.Путем выполнения простого запроса проверяется существование таблицы