Стратегия Восстановления

Рубрика: Oracle

Здравствуйте, уважаемые читатели блога okITgo.ru! Поговорим сегодня о стратегиях восстановления данных. Сразу следует принять во внимание то, что стратегия восстановления должна включать решения для любых возможных сценариев сбоя базы данных. Ключ к эффективной и результативной стратегии – в четком представлении моделей сбоев, сопоставлении их с методами восстановления Базы Данных Oracle и знании инструментов, полезных в случае того или иного сценария сбоя, а также в гарантии того, что Вы включили все необходимые типы бэкапов для поддержки выбранных методов восстановления.

Чтобы понять, как сопоставить модели сбоев с методами восстановления, пригодными для того или иного сбоя, ознакомьтесь с материалом статьи:


Планирование Реакции на Ошибку Пользователя: Восстановление На Момент Времени и Возможности Ретроспекции

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

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

Ретроспективная База Данных

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

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

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

Создание Обычных и Гарантированных Точек Реставрации

Как я уже говорил выше, гарантированные точки реставрации гарантируют, что Вы сможете вернуть вашу БД к определенному предыдущему моменту, используя Ретроспективную БД. Обычные точки восстановления не обеспечивают защиту ваших данных, но они удобны, поскольку Вам не потребуется записывать SCN базы данных перед операцией, после которой Вы возможно захотите восстановиться, используя восстановление на момент времени или ретроспективную таблицу, а также Вы избежите необходимости исследования подходящего SCN после выполнения “опасной” операции.

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

Восстановление Базы Данных На Момент Времени

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

Импорт Потерянных Объектов из Логического Бэкапа

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

Замечание:
Ретроспективная Технология Oracle обеспечивает более быстрые и менее разрушительные альтернативы восстановлению носителя при многих обстоятельствах.
  • Ретроспективная БД Oracle является механизмом восстановления физического уровня, в чем сходна с восстановлением носителя, но вообще она быстрее и не требует реставрацию данных из бэкапа.
  • Ретроспективная Таблица Oracle и Ретроспективный Сброс Oracle работают на логическом уровне, откатывая нежелательные изменения таблиц, включая обращение воздействия предложений DROP TABLE.
  • Ретроспективный Запрос Oracle и Ретроспективный Версионный Запрос Oracle полезны при просмотре прошлого содержимого таблиц и исследования как и когда логические повреждения повлияли на вашу базу данных.


Планирование Реакции на Сбой Носителя: Реставрация и Восстановление Носителя

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

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

Пример: Восстановление Онлайн Журнала Изменений (Redo)

Метод восстановления после потери всех членов группы онлайн журналов зависит от ряда факторов, таких как:

  • Состояние базы данных (открыта, после сбоя, закрыта согласованно и т.д.)
  • Была ли потерянная группа redo-журналов текущей
  • Была ли потерянная группа журналов изменений заархивированной

Например:

  • Если Вы потеряли текущую группу, а БД была закрыта согласованно (независимо от того, открыта она на данный момент или произошел сбой бд), то Вам потребуется реставрировать базу из старого бэкапа и выполнить восстановление на момент времени, после чего открыть базу, используя предложение OPEN RESETLOGS. Вы потеряете все транзакции, которые были в потерянном журнале. Также Вам потребуется сделать новый полный бэкап базы сразу после OPEN RESETLOGS. Бэкапы, сделанные до OPEN RESETLOGS будут непригодны для восстановления из-за потерянного журнала.
  • Если Вы потеряли текущую группу redo-журналов, и если база была закрыта согласованно, то Вы можете открыть ее посредством предложения OPEN RESETLOGS без потери транзакций. Однако, Вам также необходимо будет сделать новый полный бэкап БД. Бэкапы сделанные до OPEN RESETLOGS будут также непригодны для восстановления из-за потерянного журнала.
  • Если Вы потеряли не текущую группу журналов изменений, то Вы можете использовать предложение ALTER DATABASE CLEAR LOGFILE для пересоздания всех членов группы. Транзакции не будут потеряны. Если потерянная группа журналов была заархивирована прежде, чем была она была потеряна, то польше ничего не требуется. В противном случае, необходимо немедленно сделать новый полный бэкап БД. Бэкапы, сделанные до того, как был потерян журнал, будут непригодны для восстановления из-за потерянного журнала.

Планирование Реакции на Повреждение Блока Файла Данных: Восстановление Носителя Блока

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

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

Рубрика: Oracle