Планирование стратегии бэкапов 2 – выбор политики сохранения, архивация старых бэкапов, частота выполнения резервного копирования

Рубрика: Oracle

Доброго времени суток, уважаемые читатели блога okITgo.ru! Продолжим рассматривать тему, начатую в предыдущем посте рубрики Oracle о планировании стратегии бэкапов базы данных.


Выбор Политики Сохранения Бэкапов

Ваша политика сохранения бэкапов – это правило, которое Вы устанавливаете относительно того, какие бэкапы должны сохраняться (либо на диск, либо на другой носитель бэкапов), чтобы удовлетворить вашей стратегии восстановления и другим требованиям.

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

Бэкап, который более не требуется для удовлетворения политике сохранения бэкапов, называется устаревшим (англ. obsolete).

Реализация Политики Сохранения Бэкапа с помощью RMAN

RMAN автоматизирует выполнение политики сохранения бэкапов, используя следующие комманды:

  • Команда CONFIGURE RETENTION POLICY позволяет Вам установить политику сохранения, которая будет применяться ко всем файлам вашей базы данных по умолчанию.
  • Команда REPORT OBSOLETE перечисляет бэкапы, имеющиеся на диске в данный момент, которые являются устаревшими согласно политике сохранения. Вы также можете указать параметры, чтобы посмотреть, какие файлы были бы устаревшими в соответствии с другими политиками сохранения.
  • Команда DELETE OBSOLETE удаляет файлы, которые команда REPORT OBSOLETE перечисляет как устаревшие.
  • Предложение CHANGE… KEEP позволяет Вам установить отдельную политику сохранения для специфических бэкапов, таких как долгосрочные бэкапы, сохраняемые для архивных целей. Вы можете указать, что определенный бэкап должен храниться до определенного момента в будущем, или даже указать, что бэкап должен храниться вечно. Предложение CHANGE… NOKEEP используется для возобновления применения политики сохранения к бэкапу, защищенному прежде посредством CHANGE… KEEP.

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

Политика Сохранения, Основанная на Окне Восстановления

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

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

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


RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

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

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

Политика Сохранения Бэкапов, Основанная на Избыточности

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


RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

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

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


Архивация Более Старых Бэкапов

Существует несколько причин хранения более старых бэкапов файлов данных и архивных журналов:

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

Чтобы выполнить восстановление на момент времени к заданному целевому моменту, более раннему, чем ваша текущая точка восстанавливаемости, Вам потребуется бэкап базы данных, который был взят до этого целевого момента, а также и все архивные журналы, созданные между моментом взятия этого бэкапа и заданным целевым моментом времени. Например, если Вы берете полный бэкапы базы, начиная с 1:00 (часа ночи) 1-го Февраля (в SCN 10000) и 14-го Февраля (в SCN 20000), и решаете 28-го Февраля использовать восстановление на момент времени, чтобы привести вашу базу данных к ее состоянию в момент времени 9:00 (девять часов утра) 7-го Февраля (SCN 13500), то Вы должны использовать бэкап от 1-го Февраля, а также все архивные журналы, содержащие изменения между началом создания бэкапа (SCN 10000) и целевым моментом времени – 9:00 7-го Февраля (SCN 13500).


Определение Частоты Бэкапов

Частые бэкапы являются неотъемлимой частью для любой схемы восстановления. Основывайте частоту взятия бэкапов на показателе или частоте обновлений базы данных, таких как:

  • Добавление и удаление таблиц
  • Вставки и удаления строк в существующие таблицы
  • Обновления данных внутри таблиц

Чем чаще обновляется ваша база данных, тем чаще Вы должны делать бэкапы базы.

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


Выполнение Бэкапов До и После того, как Вы Делаете Структурные Изменения

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

  • Создание или сброс табличного пространства.
  • Добавление или переименование файла данных в существующем табличном пространстве.
  • Добавление, переименование или сброс группы онлайн журналов транзакций или ее члена.

Если база работает в режиме NOARCHIVELOG, то Вы должны остановить базу данных и выполнить согласованный полный бэкап базы данных целиком после любого их таких изменений. Если база работает в режиме ARCHIVELOG, то Вы должны слелать бэкап контрольного файла после любого из таких изменений, используя либо команду RMAN-а BACKUP CONTROLFILE, либо SQL предложение ALTER DATABASE BACKUP CONTROLFILE.


Планирование Бэкапов Часто-Обновляемых Табличных Пространств

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

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


Взятие Бэкапа после Операций NOLOGGING

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

Замечание:
Вы можете использовать как полный бэкап ваших файлов данных, так и инкрементальный бэкап. Любой из них захватит все изменившиеся блоки, включая блоки, измененные посредством невосстанавливаемых операций.

Экспорт Данных для Дополнительной Защиты и Гибкости

Утилиты импорта и экспорта бд Oracle используются для экспорта объектов базы (таблиц, хранимых процедур и т.д.) из баз данных для сохранения их в виде файлов, и для повторного импорта объектов из этих файлов. Экспорт предоставляет снимок логического уровня экспортированных объектов в момент экспорта, в виде бинарного файла, который может быть импортирован обратно в базу данных – источник или какую-нибудь другую базу. Рассматривайте экспортирование порций или всей базы данных как дополнительную защиту и гибкость (дополнительные возможности) в вашей стратегии бэкапа.

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


Предотвращение Бэкапа Онлайн Журналов Транзакций

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

Бэкапы онлайн журналов изменений в частности бесполезны по следующим причинам:

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

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

Замечание:
RMAN не позволяет Вам выполнять бэкап онлайн журналов транзакций. Вы должны архивировать журналы транзакций, прежде чем бэкапить их.

Хранение Записей Конфигурации Оборудования и Программного Обеспечения Сервера

Во время напряженной ситуации в процессе восстановления, важно иметь всю необходимую информацию в вашем распоряжении. Это особенно важно, если Вам по какой-либо причине необходимо обратиться в Службу Поддержки Oracle, поскольку Вы столкнулись с проблемой, которую Вы не понимаете. Вам необходимо иметь следующую документацию о конфигурации вашего оборудования:

  • Имя, производителя и модель машины, на которой работает база данных
  • Версию и патч операционной системы
  • Количество дисков и дисковых контроллеров
  • Емкость диска и свободное пространство
  • Имена всех файлов данных
  • Название и версию ПО управления носителем (если Вы используете сторонний менеджер носителя)

Также Вам необходимо иметь следующую документацию о конфигурации программного обеспечения:

  • Имя экземпляра базы данных (SID)
  • Идентификатор базы данных (DBID)
  • Версия и патч релиза сервера БД Oracle
  • Версия и патч релиза сетевого ПО
  • Способ (RMAN или пользовательский) и частота бэкапов базы
  • Метод реставрации и восстановления (RMAN или пользовательский)

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

Особенно важно хранить запись DBID. Если Вам придется реставрировать и восстанавливать вашу базу данных, включая потерянные SPFILE и контрольный файл, Вам понадобится DBID в процессе восстановления. В дальнейшем я опишу подробности того, как DBID используется во время восстановления. Можете подписаться на обновления по электронной почте, чтобы не пропустить примеры основных сценариев реставрации и восстановления базы данных. Благодарю за внимание! До новых встреч на страницах сайта okITgo.ru.

Рубрика: Oracle