Планирование стратегии бэкапа базы – Часть 1 – защита избыточного набора, fra, режимы ARCHIVELOG и NOARCHIVELOG, а также ретроспективные возможности Оракл и точек реставрации

Рубрика: Oracle

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


Защита Вашего Избыточного Набора

Набор файлов, неоходимый для восстановления любого из файлов БД Oracle после сбоя – файла данных, контрольного файла или онлайн журнала изменений—называется избыточным набором (англ. redundancy set). Избыточный набор должен содержать:

  • Последний бэкап контрольного файла и всех файлов данных
  • Все архивные журналы изменений, сгенерированные после того, как был взят этот последний бэкап данных
  • Дубликаты текущего контрольного файла и файлы онлайн журналов изменений, сгенерированные посредством мультиплексирования БД Oracle, зеркалирования ОС или того и другого
  • Копии файлов конфигурации, таких как файл параметров сервера (англ. server parameter file или сокр. spfile), tnsnames.ora и listener.ora
Предостережение:
Не храните избыточный набор на том же диске, который содержит файлы данных, онлайн журналы изменений и контрольные файлы базы данных. Иначе, диск станет единственной критической точкой базы. Если диск выйдет из строя, Вы потеряете зафиксированные транзакции.

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

Простейший способ управления вашим избыточным набором – использование мгновенной области восстановления (FRA), на отдельном устройстве от рабочего набора файлов. Однако, вне зависимости от того, используете Вы FRA или нет, Oracle приводит следующие рекомендации:

  • Мультиплексируйте файлы онлайн журнала транзакций (redo) и текущий контрольный файл на уровне базы данных. (Например, сконфигурируйте базу данных писать ее онлайн журналы в два или более местоположений, так, чтобы каждая операция записи выполнялась базой, а не на уровне ОС или избыточности на уровне оборудования.) Если Вы настроите мультиплексирование на уровне базы данных, то сбой ввода/вывода или сбой операции записи повредят только одну из копий.
  • В идеале, мультиплексированные файлы должны распологаться на разных дисках под управлением разных контроллеров дисков. Мгновенная область восстановления является отличным местом для одной из копий этих файлов.
  • Вы также можете зеркалировать онлайн журналы изменений и текущий контрольный файл на уровне ОС или на уровне оборудования, но это не замена для мультиплексирования на уровне БД.
  • При работе в режиме ARCHIVELOG архивируйте журналы транзакций в несколько местоположений, в идеале на разные диски. Если Вы используете мгновенную область восстановления, то одним из этих местоположений сделайте FRA.
  • Используйте зеркалирование контрольного файла посредством ОС или оборудования. Все копии контрольного файла, мультиплексированные на уровне БД, должны быть все время доступны, иначе произойдет сбой экземпляра. Если Вы используете зеркалирование контрольного файла средствами ОС или оборудования, ваша база данных может продолжать работать даже в случае, если одна из копий контрольного файла, зеркалированного на уровне ОС, не доступна из-за выхода из строя диска.
  • Используйте зеркалирование средствами ОС или оборудования для основных файлов данных, если это возможно, чтобы избежать выполнения восстановления носителя для простых случаев дисковых сбоев.
  • Храните по крайне мере одну копию полного избыточного набора—включая самый последний бэкап базы—на диске. Мгновенная область восстановления является идеальным местом для избыточного набора.
  • Если целевая база данных хранится на RAID устройстве, то следует хранить избыточный набор на группе дисков, которые не входят в то же самое RAID устройство.
  • Если Вы храните избыточный набор на ленте, то поддерживайте по крайней мере две копии данных, чтобы защититься от риска сбоя ленты. Кроме того, если у Вас есть более одного бэкапа одних и тех же данных, то рассмотрите возможность сохранения бэкапов данных в различные моменты времени. Таким образом, если один из бэкапов или разделенное зеркало было создано, когда БД уже повреждена, то у Вас по-прежнему будет бэкап, взятый, когда база данных еще была целой.

Решение об Использовании Мгновенной Области Восстановления (FRA)

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

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

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

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


Выбор Между Режимами ARCHIVELOG и NOARCHIVELOG

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

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

Последствия Работы в Режиме NOARCHIVELOG

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

Если Вы запускаете базу в режиме NOARCHIVELOG и должны восстановить ее после повреждения файлов данных из-за сбоя диска, Вы имеете две основных опции восстановления:

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

Последствия Работы в Режиме ARCHIVELOG

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

  • Должно быть выделено пространство в стороне для архивных местоназначений, т.е. локаций на диске, где будут сохраняться архивные журналы транзакций. Эти местоназначения могут стать довольно большими в базах данных с большим количеством обновлений.
  • Сохраняемыми архивными журналами изменений необходимо управлять. Чтобы ограничить дисковое пространство, используемое архивными журналами транзакций, эти архивные журналы изменений могут быть перемещены на ленту для длительного хранения, а более старые журналы, которые более не нужны для целей восстановления, следует удалять. (RMAN может автоматизировать большую часть управления архивными журналами транзакций, записывая местоположение и содержимое всех архивных журналов изменений, упрощая перемещение архивных журналов на ленту, и определяя и удаляя журналы транзакций, которые более не нужны для восстановления.)
  • Некоторые накладные расходы производительности связаны с фоновыми процессами ARC0 – ARCn, которые копируют заполненные онлайн журналы транзакций в архивные местоположения.

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


Решение об Использовании Ретроспективных Возможностей Оракл и Точек Реставрации

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

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

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

Рубрика: Oracle