Восстановление Данных

Рубрика: Oracle

Здравствуйте, уважаемые посетители сайта okITgo.ru! В текущей статье хочу подробнее рассказать о восстановлении данных базы Oracle. Суть процесса довольно простая, но четкое ее понимание является очень важным при администрировании сервера баз данных Oracle и собственно при выполнении такой задачи, как восстановление потерянной информации.

Процесс Восстановления Данных: Основные Концепции

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

Реставрировать файл данных или контрольный файл из бэкапа – значит скопировать файл на диск из резервной директории на диске, ленте или другом носителе, и сделать его доступным для сервера базы данных.

Восстановить файл данных (также говорят выполнить восстановление файла данных) – значит взять сохраненную копию файла данных и применить к нему изменения, записанные в redo-журналах базы данных. Восстановить базу целиком – означает выполнить восстановление каждого из ее файлов данных.

Рисунок показывает основной принцип бэкапа, реставрации и восстановления БД. Большинство процедур восстановления данных, поддерживаемых бд Oracle, являются разновидностями процесса, описанного здесь.

Реставрация и Восстановление Базы Данных

В данном примере полный бэкап базы данных (копии ее файлов данных и контролького файла) взят в момент SCN 100. Redo-журналы, генерируемые во время работы бд захватывают все изменения, которые происходят между точками SCN 100 и SCN 500. В течение этого процесса некоторые журналы заполняются полностью и архивируются. В момент SCN 500 файлы данных бд теряются из-за сбоя носителя (например, жестких дисков). База затем возвращается в транзакционно-согласованное состояние на момент SCN 500 – путем реставрации файлов данных из бэкапа, взятого в точке SCN 100, и последующего применения транзакций, сохраненных в архивных и онлайн журналах изменений, а также отмены незавершенных транзакций.

Формы Восстановления Данных

Сценарий примера выше обрисовал основы процесса реставрации и восстановления. Несколько разновидностей этого сценария важны для вашей работы по бэкапу и восстановлению.

Рассмотрим эти разновидности подробнее:

Восстановление Носителя Файлов Данных: Реставрация Файлов Данных, Применение Изменений (Redo)

Восстановление носителя файлов данных (часто называемое просто восстановление носителя) является наиболее простой формой восстановления данных, выполняемого пользователем. Она может использоваться для восстановления потерянного или поврежденного текущего файла данных, файла параметров (SPFILE) или контрольного файла. Также эта разновидность восстановления может воспролизвести изменения, которые были записаны в redo-журналы, но не в файлы данных для табличного пространства, которое было переведено в режим оффлайн без опции OFFLINE NORMAL. Восстановление носителя файлов данных может быть выполнено как с помощью Менеждера Восстановления, так и путем пользовательского бэкапа и восстановления. (Для пользовательского бэкапа и восстановления это фактически основной доступный метод.)

Необходимость реставрации файла данных из бэкапа не обнаруживается автоматически. Первым шагом в выполнении восстановления носителя является ручная реставрация файла данных путем копирования его из бэкапа. Как только файл данных реставрирован из бэкапа, база данных, однако, не обнаруживает автоматически, что этот файл данных не является современным и должен подвергнуться восстановлению носителя.

Несколько ситуаций обязывают Вас выполнить восстановление носителя:

  • Вы реставрируете файл данных из бэкапа.
  • Вы реставрируете контрольный файл из бэкапа (даже если все файлы данных являются текущими).
  • Файл данных переведен в режим оффлайн (либо Вами, либо автоматически базой данных) без опции OFFLINE NORMAL.

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

  • База данных, которой принадлежит файл данных, не должна быть открыта;

или

  • Конкретный файл данных, который необходимо восстановить, должен быть в режиме оффлайн, если база данных открыта.

Файл данных, который нуждается в восстановлении носителя, не может быть переведен в режим онлайн до тех пор, пока восстановление носителя не завершено. База не может быть открыта, если хотя бы один из онлайн файлов данных нуждается в восстановлении носителя.

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

Полное, Неполное и Восстановление на Момент-Времени

Полное восстановление – это восстановление бд к самому последнему моменту времени, без потери какой-либо из завершенных транзакций. Вообще, под термином “восстановление” обычно понимается полное восстановление.

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

Восстановление на момент времени также является единственно возможным способом, если Вы должны выполнить восстановление и обнаруживаете, что отсутствует архивный журнал, покрывающий время между бэкапом, из которого выполнена реставрация и целевым моментом SCN для восстановления. Без отсутствующего журнала Вы не имеете записи обновлений в ваших файлах данных в течении этого периода. Ваш единственный выбор в этом случае – восстановить базу с момента взятия бэкапа до как можно более позднего момента, который позволяет неразбитый ряд архивных журналов, затем выполнить OPEN RESETLOGS – в этом случае естественно все изменения в и после отсутствующего журнала будут потеряны. (Если вы обнаруживаете, что потеряли архивные журналы и ваша база данных по-прежнему открыта, то, ясное дело, нужно немедленно сделать полный бэкап, пока есть такая возможность :-))

Замечание:
Если только одно табличное пространство подверглось потере данных, Вы имеете возможность выполнения восстановления на момент времени для этого табличного пространства вместо базы данных целиком. В будущем я планирую описать восстановление на момент времени для табличного пространства (сокращенно его называют TSPITR – от англ. TableSpace Point-In-Time Recovery ).

Автоматическое Восстановление После Сбоя Экземпляра: Аварийное Восстановление

Процесс аварийного восстановления – это специальная форма восстановления, которая происходит, как только первый раз запускается экземпляр бд после аварийного отказа (или SHUTDOWN ABORT). В аварийном восстановлении цель в состоит в том, чтобы привести файлы данных в транзакционно-согласованное состояние, сохранив все завершенные транзакции вплоть до того момента, когда произошел аварийный отказ.

Как и аварийное восстановление, восстановление носителя файлов данных предназначено для сохранения целостности базы данных. Однако, существует и ряд важных отличий между ними:

  • Восстановление носителя должно быть явно инициировано пользователем. База данных не начнет восстановление носителя сама по себе.
  • Восстановление носителя применяет необходимые изменения к файлам данных, которые были реставрированы из бэкапа, а не к онлайн файлам данных, которые остались после аварийного отказа.
  • Восстановление носителя должно использовать архивные журналы так же, как и онлайн журналы, чтобы отследить изменения вплоть до того момента, когда был сделан бэкап файла данных.

В отличие от видов восстановления, выполняемых вручную после потери данных, аварийное восстановление использует только файлы онлайн redo-журналов и текущие онлайн файлы данных, которые остались на диске после сбоя экземпляра. Архивные журналы никогда не используются во время аварийного восстановления, и файлы данных никогда не реставрируются из бэкапа.

База данных применяет все незаконченные обновления в онлайн журналах изменения к онлайн файлам данных вашей БД. Результат состоит в том, что всякий раз, когда база перезагружается после аварийного сбоя, файлы данных отражают все завершенные изменения вплоть до момента, когда произошел сбой. (После того как база данных открывается, все изменения, которые были частью незавершенных транзакций на момент аварийного сбоя, откатываются назад.)

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

Надеюсь, материал оказался полезным. Далее планирую описать возможности Менеджера Восстановления RMAN. Спасибо за внимание! До новых встреч на страницах сайта okITgo.ru.

Рубрика: Oracle