Шаги, которые требуется выполнять во время восстановления базы данных Oracle, зависят от масштабов восстановления и того, каких файлов (файлов данных, управляющих файлов, онлайновых или архивных журнальных файлов) не хватает из-за возникших проблем с носителем. В этой статье мы опишем несколько наиболее типичных сценариев выполнения восстановления как с помощью утилиты RMAN, так и с помощью пользовательских процедур.
Применение RMAN для восстановления всей базы данных
Предположим, что из-за возникновения неполадки с носителем в базе данных стали недоступными все файлы данных. При наличии всех архивных журналов восстановить резервные копии и выполнить полное восстановление базы данных Oracle можно без потерь данных.
В частности, для восстановления всей базы данных необходимо сначала запустить базу данных, но оставить ее в режиме монтирования, как показано в листинге 1 ниже. Таким образом, на период восстановления она не должна быть открыта для пользователей. (В случае восстановления только какого-то табличного пространства, однако, база данных может и быть открытой для пользователей.)
C:\> RMAN TARGET / CATALOG RMAN/RMAN1@NICK Recovery Manager: Release 11.1.0.6.0 - Production on Mon Mar 31 11:25:29 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database (not started) connected to recovery catalog database RMAN> startup mount Oracle instance started database mounted . . . RMAN>
Далее потребуется восстановить файлы данных, которые были утрачены. Поскольку осуществляется восстановление всей базы данных, это значит, что далее нужно попросить утилиту RMAN восстановить все файлы данных из наборов резервных копий. Необходимая для этого команда выглядит очень просто: RESTORE DATABASE. Утилита RMAN знает, где на диске находятся файлы с резервными копиями, и копирует их в исходные места. По умолчанию RMAN будет указывать сеансу сервера восстанавливать резервные копии в местах по умолчанию, перезаписывая любые предыдущие файлы, которые уже там есть. При желании можно заставить RMAN копировать файлы и в другие места с помощью команды SET NEWNAME, как показано ниже:
RMAN> SET NEWNAME FOR DATAFILE '?/oradata/trgt/tools01.dbf' TO '/tmp/tools01.dbf'; RMAN> RESTORE DATAFILE '?/oradata/trgt/tools01.dbf';
В листинге 2 ниже показан вывод команды RESTORE DATABASE.
RMAN> RESTORE DATABASE; Starting restore at 29-MAR-08 Using channel ORA_DISK_1 channel ORA_DISK_1: sid=50 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to C:\ORACLE\PRODUCT\10.1.0\ORADATA\NICK\SYSTEM01.DBF . . . channel ORA_DISK_1: restore complete Finished restore at 29-MAR-08 RMAN>
После того, как RMAN восстановит все файлы данных, их необходимо синхронизировать с помощью архивных журналов. Команда RECOVER DATABASE применяет архивные журналы к восстановленным файлам и синхронизирует SCN-номера для всех файлов данных и управляющего файла. В листинге 3 ниже показан вывод команды RECOVER DATABASE.
RMAN> RECOVER DATABASE; Starting recover at 29-MAR-08 using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 12 is already on disk as file . . . media recovery complete Finished recover at 29-MAR-08 RMAN>
Совет. В случае применения RMAN выполнять восстановление архивных журналов не требуется, потому что RMAN автоматически применяет архивные журналы по мере необходимости во время процесса восстановления.
И, наконец, напоследок необходимо перевести базу данных в оперативный режим, чтобы пользователи могли снова получать к ней доступ:
RMAN> ALTER DATABASE OPEN; Database opened; RMAN>
Обратите внимание на то, что описанные выше шаги по восстановлению всей базы данных можно легко упростить за счет применения следующего сценария:
RMAN> RUN {
shutdown immediate;
startup mount;
restore database;
recover database;
alter database open;
}
RMAN>
Нетрудно заметить, что RMAN делает процесс восстановления базы данных очень легким. Указывать путь к какому-либо из подлежащих восстановлению файлов не требуется. RMAN выясняет, откуда следует брать файлы, выполняя их поиск в каталоге восстановления (или в управляющем файле).
Выполнение горячего восстановления с помощью RMAN
В предыдущем примере было показано, как перед восстановлением базы данных сначала нужно восстанавливать файлы данных. По умолчанию в случае применения команды RESTORE утилита RMAN выполняет восстановление файла данных из резервной копии образа или из набора резервных копий, если копия образа не доступна. И в том и в другом случае требуется ждать, пока RMAN скопирует файл в исходное место.
Однако выполнять копирование файла в исходное место вовсе необязательно. При необходимости выполнить восстановление быстро, можно сэкономить время на восстановлении файлов данных за счет использования копий образов напрямую. Для уведомления Oracle о том, что для восстановления утраченного файла используется копия образа, применяется специальная команда SWITCH, которая позволяет пропускать шаг восстановления и переходить сразу же к этапу восстановления.
По сути, команда SWITCH заставляет управляющий файл указывать на копию файла данных как на текущий файл данных, что равнозначно применению такого SQL-оператора, как ALTER DATABASE RENAME FILE. Обратите внимание, что имя файла на уровне операционной системы при этом остается неизменным.
Ниже показано, как используется команда SWITCH:
RMAN> SWITCH DATABASE TO COPY;
Эта команда приведет к выполнению горячего восстановления базы данных.
Совет. Использовать команду SWITCH DATABASE вместо RESTORE DATABASE лучше тогда, когда восстановление требуется выполнить как можно быстрее.
Пользовательский метод восстановления всей базы данных
Пользовательский процесс восстановления всей базы данных тоже начинается с восстановления всех утраченных или поврежденных файлов данных из резервной копии. Затем выполняется восстановление самой базы данных с помощью команды RECOVER DATABASE. Во время этого процесса Oracle запрашивает необходимые архивные журнальные файлы и выполняет восстановление за счет их применения. Лучше позволить Oracle автоматически применять подходящий архивный журнальный файл, чем пытаться делать это вручную.
Автоматизировать применение файлов архивных журналов повторного выполнения можно двумя способами. Первый способ заключается в использовании перед выдачей команды RECOVER DATABASE команды SET AUTORECOVERY ON, а второй — в указании прямо в команде RECOVER ключевого слова AUTOMATIC: RECOVER DATABASE AUTOMATIC.
В общем случае, шаги, требуемые для выполнения полного восстановления базы данных без применения утилиты RMAN, выглядят так, как описано ниже.
1. Восстановите файлы данных из резервной копии.
2. Запустите базу данных в режиме монтирования:
SQL> STARTUP MOUNT;
3. Воспользуйтесь показанной ниже командой RECOVER DATABASE для запуска процесса восстановления базы данных. Ключевое слово AUTOMATIC указывает Oracle применять необходимые архивные журналы повторного выполнения автоматически. В данном примере предполагается, что архивные журналы повторного выполнения находятся в принятом по умолчанию месте, которое указано в файле init.ora или SPFILE.
SQL> RECOVER AUTOMATIC DATABASE;
Если они были помещены в какое-то другое место, нужно будет указать Oracle это место либо с помощью параметра LOGSOURCE в операторе SET, либо с помощью параметра RECOVER FROM в операторе ALTER DATABASE. Ниже приведены примеры обоих этих способов указания альтернативного пути к архивным журналам повторного выполнения:
SQL> SET LOGSOURCE /new_directory; SQL> ALTER DATABASE RECOVER FROM '/new_directory';
4. Как только Oracle завершит процесс восстановления носителя, откройте базу данных:
Media recovery complete. SQL> ALTER DATABASE OPEN;
Восстановление табличного пространства
Выполнять восстановление табличного пространства необходимо в случае утраты одного или нескольких принадлежащих ему файлов и отсутствии зеркальной копии этих файлов. Восстановление табличного пространства выполняется как при закрытой, так и при открытой базе данных, и может подразумевать как выполнение полного восстановления данных, так и выполнение их восстановления до состояния на определенный момент времени в прошлом, как объяснялось в начале этой главы. В любом случае осуществлять этот процесс можно как с помощью утилиты RMAN, так и с помощью пользовательского подхода.
Применение RMAN для восстановления табличного пространства
При возникновении необходимости в восстановлении одного или нескольких табличных пространств можно использовать те же команды RESTORE и RECOVER, но на уровне табличных пространств. Поскольку дело касается только части базы данных, останавливать базу данных на период выполнения процедуры восстановления вовсе не обязательно — можно оставлять ее и открытой. Если дело касается нескольких табличных пространств или одного, но очень большого табличного пространства, конечно, при желании можно остановить базу данных и перевести ее в режим монтирования.
Ниже описаны шаги, необходимые для восстановления табличного пространства.
1. Переведите табличное пространство, которое требуется восстановить, в автономный режим. Остальная часть базы данных в таком случае будет продолжать функционировать обычным образом:
RMAN> ALTER TABLESPACE sysaux OFFLINE;
2. Выполните в отношении табличного пространства команду RESTORE TABLESPACE, как показано ниже:
RMAN> RESTORE TABLESPACE sysaux; Starting restore at 29-MAR-08 using channel ORA_DISK_1 . . . channel ORA_DISK_1: restore complete Finished restore at 29-MAR-08 RMAN>
3. Выполните в отношении табличного пространства команду RECOVER TABLESPACE:
RMAN> RECOVER TABLESPACE sysaux; Starting recover at 29-MAR-08 using channel ORA_DISK_1 starting media recovery archive log thread 1 sequence 12 is already on disk as file . . . media recovery complete Finished recover at 29-MAR-08 RMAN>
4. По завершении процесса восстановления переведите восстановленное табличное пространства обратно в оперативный режим, как показано ниже:
RMAN> ALTER TABLESPACE sysaux ONLINE;
Пользовательский метод восстановления табличного пространства
Предположим, что база данных находится в оперативном режиме, и один или несколько принадлежащих ей файлов повреждены. Если записывающему устройству базы данных не удастся выполнить запись данных в эти поврежденные файлы, Oracle автоматически переведет эти файлы в автономный режим. В противном случае потребуется самостоятельно перевести соответствующее табличное пространство в автономный режим, а затем восстановить поврежденные файлы данных и выполнить процедуру восстановления табличного пространства.
Ниже описаны необходимые шаги.
1. Переведите пострадавшее табличное пространство в автономный режим:
SQL> ALTER TABLESPACE sales01 OFFLINE IMMEDIATE;
2. Восстановите поврежденные файлы:
SQL> HOST cp /u01/app/oracle/backup/shan/sales_01.dbf /u01/app/oracle/oradata/shan/sales_01.dbf
3. Выполните восстановление отключенного табличного пространства:
SQL> RECOVER TABLESPACE sales01;
4. Переведите только что восстановленное табличное пространство обратно в оперативный режим:
SQL> ALTER TABLESPACE sales01 ONLINE;
Восстановление файла данных
Процедуры, которые нужно применять для выполнения восстановления после потери файла данных, зависят от того, к табличному пространству какого типа относится этот файл данных. Для выяснения того, какие файлы подлежат восстановлению, можно использовать динамическое представление производительности V$RECOVER_FILE.
Давайте посмотрим, что будет происходить в случае столкновения экземпляра с ошибками при взаимодействии с носителем, при условии работы в режиме archivelog. В случае столкновения экземпляра с ошибкой при чтении, лишающей его возможности прочитать файл данных, будет появляться сообщающая об этом ошибка операционной системы, но база данных будет все равно продолжать работать. При попытке базы данных выполнить запись заголовка файла во время прохождения контрольной точки будет выдаваться ошибка невозможности выполнения записи. В случае столкновения экземпляра с ошибкой при записи, лишающей его возможности выполнить запись данных в файл данных табличного пространства System или табличного пространства отката, экземпляр будет немедленно остановлен.
В случае если ошибка при записи касается другого табличного пространства, база данных будет просто переводить проблемный файл данных в автономный режим, а все остальные файлы данных в том же табличном пространстве будут оставаться доступными. Задачей администратора баз данных тогда будет восстановление пострадавшего файла данных.
В следующих подразделах описано, как выполнять восстановление утраченного файла данных, если только он не был утрачен из табличного пространства System.
Применение RMAN для восстановления файла данных
Процесс восстановления файла данных с помощью утилиты RMAN выглядит гораздо проще пользовательского метода. Прежде всего, утилите RMAN не требуется указывать, где брать файл резервной копии, потому что она автоматически отыскивает правильный файл в своем каталоге восстановления. Достаточно просто указать ей, что требуется выполнить восстановление необходимого файла данных из резервной копии и архивных журналов.
Утилита RMAN сначала восстанавливает файл (файлы) данных из резервной копии, а затем выполняет в отношении него (них) необходимую процедуру восстановления с использованием архивных журналов повторного выполнения. Она сама знает, какие архивные журналы повторного выполнения требуется применить к восстановленному из резервной копии файлу (или файлам) данных.
Давайте воспользуемся блоком RUN для восстановления файла данных, как показано в листинге 4 ниже. Процесс восстановления файла данных состоит из двух этапов: сначала нужно восстановить сам файл данных из резервной копии RMAN, что делает команда RESTORE DATAFILE, а затем выполнить в отношении этого восстановленного из резервной копии файла отдельную процедуру восстановления, что обеспечивает команда RECOVER DATAFILE.
RMAN> RUN {
2> restore datafile 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\NICK\SYSAUX01.DBF';
3> recover datafile 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\NICK\SYSAUX01.DBF';
4> }
starting full resync of recovery catalog
full resync complete
Starting restore at 12-JUL-08
using channel ORA_DISK_1
channel ORA_DISK_1: restore complete
Finished restore at 12-JUL-08
Starting recover at 12-JUL-08
using channel ORA_DISK_1
starting media recovery
. . .
media recovery complete
Finished recover at 12-JUL-08
starting full resync of recovery catalog
full resync complete
RMAN>
Обратите внимание на то, что RMAN автоматически применяет все необходимые архивные журналы повторного выполнения незаметным образом на этапе восстановления без специального приглашения.
Пользовательский метод восстановления файла данных
В случае отказа экземпляра базы данных или невозможности запустить его без ошибки в результате утраты или повреждения какого-то файла данных, вина файла данных очевидна. Однако бывает и так, что после утраты файла данных база данных все равно продолжает работать. В таком случае для выяснения того, какие файлы могут нуждаться в восстановлении, можно использовать следующий оператор:
SQL> SELECT file#, status, error, recover, tablespace_name, name FROM V$DATAFILE_HEADER WHERE RECOVER = 'YES' OR (RECOVER IS NULL AND ERROR IS NOT NULL);
Возможные результаты выполнения этого запроса следует интерпретировать следующим образом.
- Если в результате выполнения запроса возвращается сообщение no rows selected (не были выбраны никакие строки), это значит, что ни один из файлов данных не нуждается в восстановлении.
- Если в столбце ERROR содержится значение NULL, а в столбце RECOVER — значение YES, это значит, что восстановление можно выполнить и без восстановления копии файла данных.
- Если в столбце ERROR содержится какое-нибудь другое значение, а не NULL, это может свидетельствовать о наличии проблемы с носителем, точно так же как то, что в столбце RECOVER не отображается значение NO, может свидетельствовать о наличии проблемы с диском.
- Во всех предыдущих случаях, сначала нужно проверить, не является ли проблема временной и нельзя ли ее устранить без замены носителя. Если проблема не временная, придется выполнить восстановление носителя.
- Значение NULL в столбце RECOVER свидетельствует о наличии проблемы с оборудованием.
Приведенный ниже запрос к представлению V$RECOVER_FILE позволяет получить информацию о номере файла, его состоянии, ошибках и прочих деталях:
SQL> SELECT file#, error, online_status, change#, time FROM V$RECOVER_FILE;
Для восстановления после утраты файла данных при открытой базе данных сначала потребуется перевести в автономный режим соответствующее табличное пространство, а затем восстановить утраченный файл данных из резервной копии и провести процедуру восстановления самого табличного пространства. Ниже вкратце перечислены команды, которые необходимо для этого использовать:
SQL> ALTER TABLESPACE sales01 OFFLINE IMMEDIATE; SQL> HOST cp /test01/app/oracle/backup/sales01.dbf /test01/app/oracle/oradata/finance/sales01.dbf; SQL> RECOVER TABLESPACE sales01; SQL> ALTER TABLESPACE sales01 ONLINE;
Команды ALTER TABLESPACE OFFLINE и ALTER TABLESPACE ONLINE гарантируют, что у пользователей не будет доступа к табличному пространству во время процесса восстановления.
Неполное восстановление
В предыдущих примерах рассматривались сценарии полного восстановления. База данных или табличное пространство (что тоже бывает) восстанавливались полностью без потери данных. Методика неполного восстановления применяется в ситуациях, когда требуется вернуть данные в предыдущее состояние, например, из-за того, что при вводе данных была допущена ошибка, или по причине утраты оперативного журнала повторного выполнения. После такого восстановления данные в базе хоть и получаются не самыми актуальными на текущий момент, но зато являются согласованными. В следующих подразделах показано, как выполнять неполное восстановление с помощью RMAN и пользовательских процедур восстановления.
Применение RMAN для выполнения неполного восстановления
С помощью RMAN можно выполнять три вида неполного восстановления при условии, что база данных функционирует в режиме archivelog. В частности, перед использованием команд RESTORE и RECOVER можно выполнить команду SET UNTIL и указать в ней время, SCN-номер или порядковый номер журнала. Выбор того или иного варианта зависит от проблемы, которая служит причиной для выполнения неполного восстановления.
- Восстановление до указанного времени. При выполнении такого вида восстановления RMAN восстанавливает файлы в базе данных до указанного момента времени. Применять такой подход удобно, если точно известно, что проблема вроде случайного удаления таблицы произошла в конкретное время. Для выполнения восстановления до указанного времени служит команда SET UNTIL TIME, как показано в следующем примере:
SET UNTIL TIME 'Mar 21 2005 06:00:00'
- Восстановление до указанного системного номера изменения. Если известен системный номер изменения, можно выполнить восстановление до него. Для указания того, что должны использоваться файлы вплоть до данного SCN-номера, служат ключевые слова SET UNTIL SCN, например:
SET UNTIL SCN 1000
- Восстановление до указанного порядкового номера журнала. Восстановление можно выполнять до определенного порядкового номера журнала. При таком восстановлении RMAN выбирает файлы для восстановления вплоть, но не включительно, до указанного порядкового номера. Для выполнения этого вида восстановления применяется команда SET UNTIL SEQUENCE:
SET UNTIL SEQUENCE 9923
Давайте более подробно рассмотрим пример выполнения восстановления до указанного времени в масштабах текущей инкарнации базы данных. Предположим, что таблица test была случайно удалена немногим раньше шести часов вечера. В листинге 5 ниже показано, как будет выглядеть процесс восстановления.
RMAN> STARTUP MOUNT
RMAN> RUN
2> {set until time 'Jun 30 2008 18:00:00';
3> restore database;
4> recover database;
5> }
executing command: SET until clause
restoring datafile 00024 to /test02/app/oracle/oradata/temp_01.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/test01/app/oracle/oradata/backup
/2ddp387s_1_1 tag=null params=NULL
channel ORA_DISK_1: restore complete
Finished restore at 30-JUN-08
Starting recover at 30-JUN-08
using channel ORA_DISK_1
starting media recovery
media recovery complete
Finished recover at 30-JUN-08
RMAN> ALTER DATABASE OPEN RESETLOGS;
Database opened.
RMAN>
На заметку! Для успешного восстановления до определенного момента времени необходимо иметь в распоряжении резервные копии всех файлов данных, созданные до указанного целевого момента (или SCN). Также необходимо иметь все архивные журналы за период между SCN-номером резервных копий и целевым SCN.
В листинге 5 база данных сначала монтируется, но не открывается. Далее утилите RMAN указывается выполнить в отношении базы данных процедуру RESTORE (т.е. извлечь резервные копии файлов данных, которые необходимы для выполнения восстановления). Затем она должна выполнить в отношении базы данных процедуру RECOVER. Утилите RMAN известно, какие архивные журналы повторного выполнения нужно использовать, благодаря информации о резервных копиях, которая хранится в ее каталоге восстановления. RMAN применяет эти архивные журналы повторного выполнения и завершает процесс восстановления. После этого база данных открывается для пользователей с помощью команды ALTER DATABASE OPEN RESETLOGS. Поскольку было выполнено восстановление на определенный момент времени в прошлом (point-in-time recovery — PITR), также необходимо исключить вероятность случайного применения базой данных старых журналов в будущем. Для этого выполняется сброс или повторная инициализация архивных журналов повторного выполнения (за счет использования ключевого слова RESETLOGS).
Ниже приведен полный сценарий выполнения восстановления табличного пространства на определенный момент времени в прошлом с помощью RMAN.
RMAN> RUN {
Allocate channel s1 type 'sbt_tape';
Allocate channel s2 type 'sbt_tape';
Set until time '28-JUL-08 06:00:00';
Restore database;
Recover database;
Sql "alter database open reset logs";
Release channel s1;
Release channel s2;
}
После обращения к базе данных и получения подтверждения в том, что она была восстановлена до предыдущего состояния, в котором она находилась на определенный момент в прошлом, можно открывать базу данных с помощью приведенной ниже команды, чтобы отменить все изменения, которые были внесены после момента, до которого выполнялось восстановление:
RMAN> ALTER DATABASE OPEN RESETLOGS;
В частности, показанная выше команда приведет к помещению всех оперативных журналов в архив, сбросу их порядковых номеров и присвоению им новой временной метки и системного номера изменения (SCN); это исключит вероятность повреждения файлов данных из-за случайного применения более старых версий журналов повторного выполнения.
Если нужно использовать конкретный порядковый номер журнала вместо временного критерия, достаточно заменить в сценарии строку SET UNTIL TIME такой, как показано ниже:
RMAN> SET UNTIL SEQUENCE 1234;
Что собой представляет параметр RESETLOGS
Обратите внимание, что после выполнения любого вида неполного восстановления всегда производится сброс журналов повторного выполнения с помощью параметра RESETLOGS. По сути, RESETLOGS инициализирует файлы журналов повторного выполнения заново, удаляя всю информацию повторного выполнения, которая содержится в них в текущий момент, и снова устанавливает для порядкового номера журнала значение 1. Для применения любых архивных журналов повторного выполнения к файлу данных SCN-номера и метки времени в файлах базы данных должны совпадать с SCN-номерами и метками времени в заголовках архивных журналов повторного выполнения, а при выполнении операции RESETLOGS файлам данных присваиваются новые SCN-номера и метки времени, что делает невозможным ошибочное применение к ним более старых архивных журналов повторного выполнения.
Параметр RESETLOGS применяется при следующих обстоятельствах:
- когда для восстановления используется резервная копия управляющего файла;
- когда выполняется неполное восстановление вместо полного;
- когда при восстановлении применяется управляющий файл, созданный с использованием параметра RESETLOGS.
В случае выполнения неполного восстановления с указанием SCN-номера команда SET UNTIL должна иметь вид SET UNTIL SCN nnnn, а для неполного восстановления с указанием порядкового номера архивного журнала — SET UNTIL LOGSEQ=nnnn THREAD=nnnn, где LOGSEQ указывает журнал, до которого требуется выполнить восстановление.
Ниже приведен короткий сценарий, показывающий, как с помощью RMAN выполнить неполное восстановление до SCN-номера:
RMAN> RUN
{
ALLOCATE CHANNEL ch1 TYPE sbt;
RESTORE DATABASE;
RECOVER DATABASE UNTIL SCN 1000; # восстановления вплоть до SCN 999
ALTER DATABASE OPEN RESETLOGS;
}
Выполнение восстановления с использованием текущей и предшествующей инкарнации базы данных
Всякий раз, когда применяется команда OPEN RESETLOGS, происходит изменение инкарнации базы данных, и начинает действие новая инкарнация. Предыдущая инкарнация называется предшествующей (ancestor incarnation), а новая — текущей (current incarnation). Утилита RMAN умеет выполнять восстановление с использованием нескольких инкарнаций базы данных. Например, при наличии резервных копий из более старой инкарнации базы данных, их можно использовать для выполнения восстановления текущей инкарнации базы данных; главное — указать, что они происходят из предыдущей инкарнации.
Использовать архивные журналы повторного выполнения из более ранней инкарнации базы данных позволяет функция Simplified Recovery Through Resetlogs (Упрощенное восстановление за счет сброса журналов). По умолчанию формат, используемый для параметра инициализации LOG_ARCHIVE_FORMAT, теперь включает компонент %r, под которым подразумевается идентификатор RESETLOGS.
Например, в системе UNIX/Linux для архивных журналов будет использоваться формат log%t_%s_%r.arc. Под переменной t подразумевается номер потока, а под переменной s — порядковый номер журнала. В представлении V$LOG_HISTORY есть два столбца — RESETLOGS_CHANGE# и RESETLOGS_TIME, которые показывают, в какой инкарнации базы данных находятся архивные журналы повторного выполнения.
В примере восстановления на определенный момент времени в прошлом, который приводился выше, использовалась текущая инкарнакция базы данных. Поэтому давайте рассмотрим пример выполнения неполного восстановления базы данных с использованием родительской инкарнации базы данных. Предположим, что требуется указать SCN-номер, находящийся не в текущей, а в предшествующей инкарнации. Для выполнения такого вида восстановления на определенных момент времени в прошлом существуют два требования.
- Нужно обязательно переустановить текущую инкарнацию базы данных обратно в ту инкарнацию, которой принадлежит целевой SCN-номер.
- Необходимо обязательно использовать управляющий файл из более старой инкарнации, т.е. из той, в которой содержится целевой SCN-номер.
Ниже перечислены шаги, требуемые для выполнения неполного восстановления с использованием более старой инкарнации.
1. Найдите ключ инкарнации, которая была текущей на момент времени в прошлом, до которого требуется восстановить базу данных. Отыскать его можно в выводе RMAN-команды LIST INCARNATION внутри столбца с соответствующим именем. Пусть в настоящем примере этим ключом будет 2.
2. Запустите базу данных следующим образом:
RMAN> STARTUP FORCE NOMOUNT;
3. Сбросьте текущую инкарнацию в инкарнацию, которая была текущей в момент времени в прошлом, до которого требуется выполнить восстановление:
RMAN> RESET DATABASE TO INCARNATION 2;
4. Восстановите старый управляющий файл из резервной копии и смонтируйте базу данных с помощью следующих команд:
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; RMAN> ALTER DATABASE MOUNT;
5. Выполните в отношении базы данных процедуру RESTORE и восстановите ее до определенного момента времени в прошлом или до определенного SCN:
RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE UNTIL SCN 1000;
6. Откройте базу данных после сброса файлов оперативных журналов повторного выполнения:
RMAN> ALTER DATABASE OPEN RESETLOGS;
Описанный выше процесс восстановления называется в Oracle опцией Simplified Recovery Through Resetlogs. Этой опцией удобно пользоваться при выполнении восстановления на определенный момент в прошлом или при выполнении восстановления с применением резервной копии управляющего файла и использовании для открытия базы данных параметра RESETLOGS. Во всех этих случаях все равно можно использовать резервную копию, созданную до операции RESETLOGS.
Пользовательский метод выполнения неполного восстановления
Выполнение неполного восстановления с помощью RMAN уже было рассмотрено, поэтому давайте посмотрим, как его выполнять вручную. Предположим, что база данных находится в открытом состоянии и принимается решение выполнить ее неполное восстановление, т.е. вернуть ее обратно до состояния, в котором она была в некий момент времени в прошлом, либо из-за того, что все внесенные с того момента изменения были утрачены (например, из-за допущения каким-то пользователем ошибки), либо из-за того, что другого выбора просто нет (например, потому, что для выполнения восстановления до актуального состояния есть не все необходимые архивные журналы повторного выполнения). Ниже перечислены шаги, которые потребуется выполнить в таком случае.
1. Немедленно остановите базу данных:
SQL> SHUTDOWN ABORT;
2. Восстановите все файлы данных и удостоверьтесь в том, что все они находятся в оперативном режиме.
3. Выберите одну из следующих команд RECOVER для выполнения процедуры восстановления, в зависимости от ситуации:
- Восстановление до отмены. Этот метод подразумевает разрешение Oracle применять архивные журналы повторного выполнения до тех пор, пока процесс восстановления не будет отменен. Его удобно использовать, например, при наличии в архивных журналах повторного выполнения какого-нибудь пробела. Необходимая команда выглядит так:
SQL> RECOVER DATABASE UNTIL CANCEL;
- Восстановление до определенного момента времени в прошлом. Этот метод подразумевает указание момента времени, до которого требуется восстановить базу данных, например:
SQL> RECOVER DATABASE UNTIL TIME '2005-06-30:12:00:00';
В случае применения резервной копии управляющего файла вместо предыдущей команды нужно использовать такую:
SQL> RECOVER DATABASE UNTIL TIME
'2005-06-30:12:00:00' USING BACKUP CONTROLFILE;
- Восстановление до определенного изменения. Этот метод подразумевает выяснение SCN-номера, до которого требуется вернуться, и указание его в команде:
SQL> RECOVER DATABASE UNTIL CHANGE 27845;
4. Независимо от того, какой из трех методов был выбран для восстановления, по завершении процесса восстановления нужно обязательно выполнить приведенную ниже команду, поскольку речь идет о неполном восстановлении:
SQL> ALTER DATABASE OPEN RESETLOGS;
Восстановление после потери управляющих файлов
В случае недоступности одного или всех управляющих файлов экземпляр базы данных немедленно останавливается. В частности, возможны два следующих сценария.
- Даже в случае потери лишь одной копии дуплексного управляющего файла, работа экземпляра немедленно завершается аварийным образом и тогда требуется просто скопировать дуплексный управляющий файл в то же место, в котором находился утраченный или поврежденный файл. При невозможности разместить его в том же месте, можно попробовать обновить файл параметров (а именно — параметр CONTROL_FILES в нем) и указать новое место. Если произвести замену утраченного управляющего файла все равно по какой-то причине не удается, останется только отредактировать файл параметров инициализации, чтобы он больше не ссылался на утраченный управляющий файл. После этого экземпляр можно снова запускать.
- В случае потери всех управляющих файлов потребуется выполнить восстановление управляющего файла из резервной копии или создать новый. В случае применения первого способа нужно обязательно провести процедуру восстановления носителя на уровне всей базы данных и затем выполнить операцию OPEN RESETLOGS.
В следующих подразделах показано, как выполнить восстановление после потери всех управляющих файлов. Подразумевается, что резервная копия управляющего файла уже существует.
Применение RMAN для выполнения восстановления после потери управляющих файлов
В этом разделе предлагается сымитировать потерю управляющих файлов путем удаления их обоих. Прежде чем делать это, обязательно удостоверьтесь в наличии резервной копии базы данных и резервной копии управляющих файлов в том числе.
После удаления управляющих файлов можно приступить к выполнению следующих шагов.
1. Остановите базу данных и попытайтесь запустить ее. Экземпляр запустится и попробует смонтировать базу данных, но когда не обнаружит управляющих файлов, прервет операцию монтирования базы данных:
RMAN> SHUTDOWN IMMEDIATE; database closed database dismounted Oracle instance shut down RMAN> RMAN> STARTUP Oracle instance started RMAN-00571: RMAN-00569: ERROR MESSAGE STACK FOLLOWS RMAN-00571: RMAN-03002: failure of startup command at 07/11/2008 17:18:05 ORA-00205: error in identifying controlfile, check alert log for more info RMAN>
Появления показанных выше сообщений об ошибке можно избежать за счет применения альтернативной команды STARTUP NOMOUNT:
RMAN> SHUTDOWN IMMEDIATE; database closed database dismounted Oracle instance shut down RMAN> RMAN> STARTUP NOMOUNT; connected to target database (not started) Oracle instance started . . . RMAN>
2. Выполните команду RESTORE CONTROLFILE, чтобы утилита RMAN могла скопировать резервные копии управляющих файлов в их исходные места, указанные в файле init.ora:
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; Starting restore at 14-JUL-08 allocated channel: ORA_DISK_1 . . . output filename=C:\ORACLE\PRODUCT\10.1.0\ORADATA\NICK\CONTROL03.CTL Finished restore at 14-JUL-08 RMAN>
3. По окончании процедуры восстановления управляющих файлов из резервных копий смонтируйте базу данных:
RMAN> ALTER DATABASE MOUNT; database mounted RMAN>
4. Проведите процедуру восстановления работоспособности базы данных, как показано в листинге 6:
RMAN> RECOVER DATABASE; Starting recover at 14-JUL-08 Starting implicit crosscheck backup at 14-JUL-08 Crosschecked 5 objects Finished implicit crosscheck backup at 14-JUL-08 Starting implicit crosscheck copy at 14-JUL-08 Finished implicit crosscheck copy at 14-JUL-08 searching for all files in the recovery area cataloging files... cataloging done starting media recovery media recovery complete Finished recover at 14-JUL-08 RMAN>
Из-за того, что утилита RMAN восстанавливала управляющие файлы из своих резервных копий, открыть базу данных нужно обязательно с использованием параметра RESETLOGS:
RMAN> ALTER DATABASE OPEN RESETLOGS; database opened new incarnation of database registered in recovery catalog starting full resync of recovery catalog full resync complete RMAN>
Пользовательский метод выполнения восстановления после потери управляющих файлов
В случае потери всех управляющих файлов, с помощью команды CREATE CONTROLFILE можно создать совершенно новый управляющий файл. В листинге 7 показан типичный оператор создания управляющего файла, полученный за счет использования вывода оператора ALTER DATABASE BACKUP CONTROLFILE TO TRACE. Сам SQL-оператор, вывод которого применяется позже для выполнения оператора CREATE CONTROLFILE, выглядит так:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE; Database altered. SQL>
Совет. Даже не имея резервной копии управляющего файла, можно легко создавать новый управляющий файл при условии, что в распоряжении имеется полный перечень всех файлов данных и файлов журналов повторного выполнения, которые входят в состав базы данных.
После выполнения оператора ALTER DATABASE BACKUP CONTROLFILE TO TRACE несложно извлечь трассировочный файл, как показано в листинге 7 ниже, из каталога трассировки, каковым обычно является udump.
Dump file c:\oracle\product\10.1.0\admin\NICK\udump\NICK_ora_2452.trc Sun Jul 10 16:35:47 2008 ORACLE Version 11.1.0.0.0 - Production vsnsta=0 The following commands will create a new control file and use it -- to open the database. -- Data used by Recovery Manager will be lost. -- Additional logs may be required for media recovery of offline -- Use this only if the current versions of all online logs are -- available. -- Следующие команды приведут к созданию нового управляющего файла -- и его применению для открытия базы данных. -- Данные, использованные диспетчером восстановления, будут утрачены. -- Дополнительные журналы могут потребоваться для выполнения восстановления -- носителя на автономном уровне. -- Применяйте этот подход только в том случае, если доступны текущие версии -- всех оперативных журналов повторного выполнения. STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE "NICK" NORESETLOGS ARCHIVELOG MAXLOGFILES 5 MAXLOGMEMBERS 2 MAXDATAFILES 200 MAXINSTANCES 1 MAXLOGHISTORY 454 LOGFILE GROUP 1 'C:\ORACLE\PROD\11.1.0\ORADATA\NICK\REDO01.LOG' SIZE 100M, GROUP 2 'C:\ORACLE\PROD\11.1.0\ORADATA\NICK\REDO02.LOG' SIZE 100M -- STANDBY LOGFILE DATAFILE 'C:\ORACLE\PRODUCT\11.1.0\ORADATA\NICK\SYSTEM01.DBF', 'C:\ORACLE\PRODUCT\11.1.0\ORADATA\NICK\UNDOTBS01.DBF', 'C:\ORACLE\PRODUCT\11.1.0\ORADATA\NICK\SYSAUX01.DBF' CHARACTER SET US7ASCII; -- Commands to re-create incarnation table -- Below log names MUST be changed to existing filenames on -- disk. Any one log file from each branch can be used to -- re-create incarnation records. -- Команды для воссоздания таблицы инкарнации. -- Приведенные ниже имена журналов нужно ОБЯЗАТЕЛЬНО заменить существующими -- именами файлов на диске. Для воссоздания записей таблицы инкарнации может -- использоваться любой файл журнала из каждой ветви. -- ALTER DATABASE REGISTER LOGFILE 'C:\ORACLE\PRODUCT\11.1.0\ FLASH_RECOVERY_AREA\NICK\ARCHIVELOG\ 2008_07_10\O1_MF_1_1_%U_.ARC'; -- ALTER DATABASE REGISTER LOGFILE 'C:\ORACLE\PRODUCT\11.1.0\ FLASH_RECOVERY_AREA\NICK\ARCHIVELOG\ 2008_07_10\O1_MF_1_1_%U_.ARC'; -- Recovery is required if any of the datafiles are restored backups, -- or if the last shutdown was not normal or immediate. -- Выполнять процедуру восстановления работоспособности базы данных необходимо, -- если хоть какой-то из файлов данных восстанавливался из резервной копии или -- если в последний раз работа базы данных была завершена необычным или -- немедленным образом. RECOVER DATABASE -- All logs need archiving and a log switch is needed. -- Нужно архивировать все журналы и выполнить переключение журнальных файлов. ALTER SYSTEM ARCHIVE LOG ALL; -- Database can now be opened normally. -- Теперь базу данных можно открыть обычным образом. ALTER DATABASE OPEN; -- No tempfile entries found to add. -- Записи tempfile, предназначенные для добавления, не обнаружены.
Как не трудно заметить, подвох при создании своего собственного оператора CREATE CONTROLFILE состоит в том, что требуется обязательно иметь точный список всех компонентных файлов базы данных. Давайте более подробно рассмотрим показанный сценарий создания управляющего файла.
Сначала в этом сценарии предпринимается попытка запустить базу данных не в режиме монтирования. Очевидно, что если управляющих файлов нет, операция монтирования базы данных завершится неудачей. Следующая строка, в которой содержится оператор CREATE CONTROLFILE, является самой критически важной в сценарии. Если все файлы журналов повторного выполнения остались нетронутыми, необходимо использовать параметр NORESETLOGS, чтобы позволить Oracle прибегнуть к помощи журналов повторного выполнения. Если же журналы повторного выполнения были утрачены или повреждены, в операторе CREATE CONTROLFILE необходимо указать параметр RESETLOGS. В таком случае Oracle создаст новые файлы журналов повторного выполнения или, если таковые уже существуют, инициализирует их заново, что, по сути, приведет к созданию нового набора таких файлов. Параметр REUSE указывает Oracle, что любые старые управляющие файлы, если таковые существуют в исходных местах, нужно перезаписать.
В листинге 8 показано, как использовать оператор CREATE CONTROLFILE из листинга 7:
SQL> STARTUP NOMOUNT ORACLE instance started. Total System Global Area 118255568 bytes Fixed Size 282576 bytes Variable Size 83886080 bytes Database Buffers 33554432 bytes Redo Buffers 532480 bytes SQL> SQL> CREATE CONTROLFILE REUSE DATABASE "NICK" NORESETLOGS ARCHIVELOG . . . Control file created. SQL> SQL> RECOVER DATABASE ORA-00283: recovery session canceled due to errors ORA-00283: сеанс восстановления был отменен из-за ошибок ORA-00264: no recovery required ORA-00264: никакой процедуры восстановления работоспособности не потребовалось SQL> ALTER SYSTEM ARCHIVE LOG ALL; System altered. SQL> ALTER DATABASE OPEN; Database altered. SQL>
Восстановление файла данных без резервной копии
Предположим, что был добавлен новый файл данных и пользователи, следовательно, начали создавать в нем какие-то объекты. Перед запланированной на выходные процедурой резервного копирования, однако, этот файл неожиданно повредился и теперь его данные требуется восстановить. В архивных журналах повторного выполнения с момента последнего резервного копирования будет содержаться информация, касающаяся утраченного файла, и, следовательно, его данные можно будет восстановить с их помощью. В следующих подразделах описаны процедуры, которые для этого понадобятся.
Применение RMAN для восстановления файла без резервной копии
Предположим, что повреждение файла впервые обнаруживается при обращении к утраченному или поврежденному файлу и получении следующей ошибки:
SQL> CREATE TABLE x (name varchar2 (30)); create table x (name varchar2 (30)) * ERROR at line 1: ORA-01116: error in opening database file 5 (ошибка при открытии пятого файла базы данных) ORA-01110: data file 5: '/test02/app/oracle/oradata/finance1/test01.dbf'
Шаги, которые потребуется выполнить, чтобы устранить проблему в таком случае, выглядят следующим образом.
1. Переведите пострадавший файл данных в автономный режим:
RMAN> SQL "alter database datafile 2> ''/test01/app/oracle/oradata/remorse/sales_01.dbf'' offline"; sql statement: alter database datafile ''/test01/app/oracle/oradata/remorse/sales_01.dbf'' offline RMAN>
2. Создайте новый файл данных с таким же именем, как и у того, который был поврежден и переведен в автономный режим:
RMAN> sql "alter database create datafile 2> ''/test02/app/oracle/oradata/remorse/sales01.dbf'' "; sql statement: alter database create datafile ''/test02/app/oracle/oradata/remorse/sales01.dbf" RMAN>
3. Выполните в отношении нового файла данных процедуру RECOVER. Утилита RMAN извлечет данные из архивных журналов повторного выполнения, благодаря чему новый файл данных станет идентичным утраченному:
RMAN> RECOVER DATAFILE '/test01/app/oracle/oradata/remorse/sales_01.dbf'; Starting recover at 30-JUN-08 using channel ORA_DISK_1 using channel ORA_DISK_2 using channel ORA_DISK_3 using channel ORA_DISK_4 starting media recovery media recovery complete Finished recover at 30-JUN-08 RMAN>
4. Переведите новый файл данных обратно в оперативный режим:
RMAN> SQL "alter database datafile 2> ''/test02/app/oracle/oradata/finance1/test01.dbf'' online"; sql statement: alter database datafile ''/test02/app/oracle/oradata/remorse/sales01.dbf'' online RMAN> EXIT
Пользовательский метод восстановления файла без резервной копии
Процедура восстановления файла вручную без применения предыдущих резервных копий выглядит очень просто, но опять-таки подразумевает наличие доступа ко всем архивным журналам повторного выполнения. Сначала создается новый файл с таким же именем, как и у того, что был утрачен, а затем выполняется восстановление данных, которые были в том файле, с использованием архивных журналов (при наличии необходимости).
