Восстановление экземпляра (Instance Recovery), в отличие от восстановления среды, выполняется автоматически сервером Oracle. При восстановлении экземпляра база данных восстанавливается до состояния, предшествующего сбою экземпляра. Восстановление экземпляра включает накат зафиксированных в оперативных журналах подтвержденных и неподтвержденных транзакций, и, затем, откат неподтвержденных транзакций до их первоначального состояния.
Восстановление экземпляра – это автоматическое применение оперативных журналов к блокам данных Oracle после сбоя экземпляра. При корректном завершении работы базы данных (NORMAL, IMMEDIATE) все изменения данных, хранящиеся в оперативной памяти, записываются на диск, т. к. при нормальном завершении всегда выполняется контрольная точка.
Однако если произошел сбой экземпляра (аварийное завершение или закрытие базы данных в режиме ABORT), при следующем запуске базы данных сервер Oracle автоматически выполнит восстановление экземпляра.
Содержимое кэша буферов в SGA записывается на диск согласно алгоритму LRU, не согласуясь с подтверждением или откатом транзакций пользователем. Поэтому файлы данных могут содержать как блоки данных, измененные неподтвержденными транзакциями, так и не измененные блоки данных, несмотря на то, что транзакция, изменившая их, была подтверждена.
· Блоки данных, измененные транзакцией, могут оказаться не записанными на диск при подтверждении транзакции, и изменения будут зафиксированы только в оперативном журнале. Следовательно, оперативный журнал содержит изменения, которые должны быть применены к базе данных во время восстановления.
· После применения журнальных записей файлы данных могут содержать изменения, которые не были подтверждены ко времени сбоя экземпляра, но были сохранены в файлах данных перед сбоем, или произошли в результате применения записей журнала. Эти неподтвержденные изменения необходимо откатить, чтобы гарантировать целостность транзакций.
Чтобы разрешить эту проблему, Oracle восстанавливает экземпляр в два этапа: восстановление кэша (Cache Recovery), при котором происходит накат (Rolling Forward) журнальных записей и, затем, восстановление транзакций (Transaction Recovery), при котором происходит откат (Rolling Back) неподтвержденных транзакций с помощью сегментов отката:
· На этапе восстановления кэша Oracle применяет к блокам данных все подтвержденные и неподтвержденные изменения, зафиксированные в оперативных журналах. На этом этапе используется журнал.
· На этапе восстановления транзакций изменения, которые не были подтверждены к моменту сбоя экземпляра, откатываются до их первоначального состояния. Чтобы откатить неподтвержденные изменения, Oracle применяет сегменты отката.
В случае потери или неисправности файлов данных или управляющего файла автоматическое восстановление экземпляра не поможет, здесь может понадобиться вмешательство администратора базы данных и применение архивных журналов к блокам данных. Восстановление среды может понадобиться, также, при возникновении пользовательской ошибки, если необходимо восстановить состояние базы данных на какой-то предшествующий момент времени.
Восстановление среды происходит по тому же сценарию, что и восстановление экземпляра, т. е. в два этапа, включающих восстановление кэша и восстановление транзакций. Однако восстановление среды имеет свои особенности:
· Перед восстановлением базы данных необходимо восстановить испорченные или потерянные файлы данных из физической резервной копии.
· Для восстановления кроме оперативных журналов могут потребоваться архивные журналы.
· Восстановление базы данных требует явного вмешательства администратора.
· Сбой носителя не определяется автоматически. Однако после того как файлы данных будут восстановлены из резервной копии, Oracle автоматически определит, что требуется восстановление базы данных.
Если база данных была запущена в режиме ARCHIVELOG, ее можно восстановить как до текущего момента, так и до какого-то предшествующего момента во времени. Восстановление базы данных на текущий момент времени называется полным восстановлением (Complete Recovery), а восстановление базы данных на момент времени, предшествующий текущему, называется неполным восстановлением (Incomplete Recovery).
Восстановление базы данных на текущий момент времени называется полным восстановлением (Complete Recovery), т. к. требует применения всех архивных и оперативных журналов к файлам данных, восстановленным из резервной копии. Обычно полное восстановление применяется в случаях, когда потеряны файлы данных или управляющий файл. Администратор может восстановить базу данных целиком, отдельное табличное пространство или файл данных. При полном восстановлении база данных восстанавливается до самого последнего SCN, зарегистрированного в управляющем файле.
Перед восстановлением базы данных необходимо восстановить поврежденные файлы данных из самой последней резервной копии. Не восстанавливайте неповрежденные файлы данных, файлы оперативного журнала и управляющий файл. Если файлы данных невозможно восстановить на старом месте, восстановите их в другом месте и переопределите их местоположение в управляющем файле, выполнив команду SQL:
ALTER DATABASE RENAME FILE ‘имя_файла’ TO ‘имя_файла’
Чтобы переопределить местоположение файлов данных в управляющем файле, база данных должна быть смонтирована, но не открыта (STARTUP MOUNT), или табличное пространство, которому принадлежат файлы данных, должно быть переведено в автономное состояние (ALTER TABLESPACE табличное_пространство OFFLINE).
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.