Перед применением каждого журнала Oracle сделает запрос, применить журнал или прервать восстановление. Если восстановление необходимо прервать, на запрос следует ответить CANCEL.
· До заданного времени
RECOVER DATABASE UNTIL TIME ‘yyyy-mm-dd:hh24:mi:ss’ [USING BACKUP CONTROLFILE]
Oracle автоматически прекратит восстановление базы данных, когда достигнет заданного времени.
· До заданного системного номера
RECOVER DATABASE UNTIL CHANGE системный_номер [USING BACKUP CONTROLFILE]
Oracle автоматически прекратит восстановление базы данных, когда достигнет заданного SCN.
· Откройте базу данных, переустановив номера журналов, чтобы синхронизировать SCN в заголовках файлов данных
ALTER DATABASE OPEN RESETLOGS
· Остановите базу данных в нормальном режиме, сделайте полную «холодную» резервную копию базы данных.
Начиная с версии Oracle8 в состав программного обеспечения сервера Oracle входит диспетчер восстановления (Recovery Manager), который предоставляет все возможности по резервному копированию и восстановлению, как из командной строки, так и с помощью графического интерфейса. Кроме стандартных возможностей, Recovery Manager (RMAN) позволяет выполнять следующие действия:
· В процессе копирования выполняется проверка корректности блоков базы данных и отсутствия повреждений.
· Поддерживается кумулятивное и инкрементное копирование:
· кумулятивное копирование (cumulative backup) – копируются все блоки, изменявшиеся с момента последнего резервного копирования;
· инкрементное копирование (incremental backup) – копируются все блоки, изменявшиеся с момента последнего кумулятивного или полного резервного копирования.
· Предоставляет встроенную систему каталогизации.
Тем не менее, несмотря на дополнительные возможности, многогранность RMAN делает его слишком громоздким для решения простых задач. К тому же для получения полной функциональности диспетчера восстановления, необходимо создать каталог восстановления в другой базе данных, чтобы сделать его доступным даже в том случае, если копируемая база данных не доступна.
Программное обеспечение Oracle9i Data Guard, работающее с производственной базой данных и с одной или несколькими резервными базами данных, предназначено для защиты данных от потерь и ошибок, которые могут вывести из строя производственную базу данных. Data Guard автоматизирует процесс поддержки транзакционально-согласованной копии производственной базы данных, которая называется резервной базой данных (Standby Database), и которая может использоваться при выходе из строя производственной базы данных, особенно в тех случаях, когда производственный процесс не может быть прерван.
В конфигурации Data Guard на производственную базу данных ссылаются, как на первичную базу данных (Primary Database). Используя резервную копию первичной базы данных, Вы можете создать от одной до девяти физических и логических резервных баз данных и включить их в конфигурацию Data Guard. Каждая резервная база данных связана только с одной первичной базой данных. Одна первичная база данных может поддерживать несколько физических и/или логических резервных баз данных:
· Физическая резервная база данных физически идентична первичной базе данных, и обновляется путем восстановления базы данных. Физическая резервная копия может быть смонтирована для восстановления данных (и не доступна для чтения) или открыта «только на чтение» для генерации отчетов (и не доступна для восстановления данных).
· Логическая резервная база данных логически идентична первичной базе данных, и обновляется путем выполнения SQL-утверждений. Таблицы в логической резервной базе данных могут одновременно использоваться как для восстановления данных, так и для других задач, таких как генерация отчетов, подведение итогов, и выполнение запросов к базе данных.
Oracle9i Data Guard поддерживает каждую резервную базу данных, как транзакционально-согласованную копию первичной базы данных, используя стандартные оперативные журналы Oracle. Изменения, примененные к данным в первичной базе данных, фиксируются в оперативных журналах первичной базы данных, затем архивируются на резервную базу данных с помощью сервисов транспортировки журналов, и, наконец, применяются к резервной базе данных с помощью сервисов применения журналов:
· Сервисы транспортировки журналов (Log transport services) управляют автоматизированной передачей архивных журналов с первичной базы данных на одну или несколько резервных баз данных. Сервисы транспортировки журналов передают журнальные файлы на локальные или удаленные, физические или логические резервные базы данных. Сервисы могут быть настроены таким образом, чтобы оптимально сбалансировать защиту данных и производительность системы.
· Сервисы применения журналов (Log apply services) по-разному применяют архивные журналы к физическим и логическим резервным базам данных (см. Рисунок 3):
o К физической резервной базе данных архивные журналы применяются, когда она смонтирована для восстановления данных, но не тогда, когда она открыта в режиме «только на чтение».
o К логической резервной базе данных архивные журналы применяются путем конвертирования журнальных данных в SQL-утверждения и применения их к открытой логической резервной базе данных. Т. к. база данных остается открытой, ее таблицы могут использоваться для других целей, таких как генерация отчетов, подведение итогов, и выполнение запросов к базе данных.
Рисунок 3 Применение журналов к физической и логической резервной базе данных
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.