Oracle database: возврат к точке до сбоя.

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

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

Самый простой инструмент создания резервной копии – это копирования файлов базы данных. Единственное, в этот момент база данных должна быть остановлена. Соответственно, процедура восстановления – это копирования файлов данных в исходное место. Недостатки метода очевидны: это прерывание в обслуживании, это “сброс” кэша базы данных и отсутствие гибкости в получении состояния СУБД на время, отличное от времени создания резервной копии. Как правило, такой метод используют, если СУБД небольшого размера, выполняет второстепенную функцию, используется для тестирования и т.п. Так же метод достаточно нетривиально реализуем на практике в случае использования ASM.

Основным и самым популярным инструментом резервного копирования СУБД Oracle является RMAN. Нужно не забывать, что для работы RMAN база должна находиться в режиме archievelog, а для корректного восстановления СУБД необходимо дополнительно выполнять резервное копирование журналов транзакций (можно выполнять резервное копирование средствами RMAN и базы, работающей в режиме noarchievelog, но в данном случае работа пользователей с СУБД будет невозможна, т.к. СУБД должна быть в статусе mount). RMAN умеет делать резервную копию в несколько потоков, но фактическое количество потоков нет смысла делать большим, чем количество файлов данных СУБД (datafile), если не использовать multisection backup. К примеру, если у вас будет некая база данных, в которой будет 8 файлов данных, один из которых будет типа bigfile и иметь размер существенно больше остальных, то скорость создания (и как следствие, восстановления) из резервной копии будет определятся именно временем создания и восстановления из резервной копии этого файла данных в 1 поток. Выход, как я писал ранее, разбитие при резервном копировании файлов данных на секции. Это позволяет снизить как время создания резервной копии, так и время восстановления из нее, причем иногда на порядок. Средствами RMAN можно восстановить как базу данных целиком, так и отдельные табличные пространства (RMAN TSPITR), не забывая правда об ограничениях. RMAN же используется для восстановления отдельной таблицы (с ограничениями). RMAN позволяет восстановить состояние базы/табличного пространства/таблицы как по состоянию до определенного SCN, так и до определенной временной точки. Очевидным недостатком метода является большое время, необходимое для восстановления работоспособности СУБД, если речь идет о значительных объемах данных (от 1Тб и более). Время восстановления, в таком случае, может занимать часы или даже десятки часов, что не всегда приемлемо и допустимо. Какие же еще есть варианты?

В последнее время распространение получили моментальные снимки томов. Современные системы хранения данных позволяют создавать более 256 снимков томов в пределах одной системы. Сам снимок создается за очень короткий промежуток времени: секунды, и время его создания не зависит от размера тома. В последующем система может быть либо возвращена к состоянию на момент создания снимка тома, либо снимок тома может быть презентован и оттуда выполнен экспорт данных, необходимых для восстановления. Вроде бы все хорошо, но… Во-первых, для создания консистентного снимка тома, на котором расположена СУБД, база данных должна находиться в состоянии, когда не осуществляются никакие операции записи,  quiesce mode: в этом состоянии работа пользователей в СУБД невозможна. Как выход из положения – создание мгновенных снимков томов резервной базы данных (standby) (к слову, и резервное копирование с точки зрения балансировки нагрузки, лучше делать с резервной базы данных). Во-вторых, на сайте oracle есть интересная статья: snapshots – are not backups. В статье описывается технология создания моментальных снимков и в конце дается предупреждение, что ввиду того, что моментальные снимки и сама база данных хранятся на одной системе хранения, они подвержены риску повреждения в случае сбоев на СХД. Так же сама по себе технология создания мгновенных снимков ведет к снижению производительности СХД. Что же осталось еще в арсенале?

Oracle Flashback Technologies. Технология позволяет вернуть к более раннему состоянию как базу данных целиком (Flashback Database), так и отдельные таблицы (Flashback Table) и даже транзакции (Flashback Transaction Query). Суть технологии достаточно простая: в базе данных включается механизм ведения дополнительного журнала изменений. В дополнение к журналам транзакций начинается писаться flashback log. Пишется он в область fra. Лог этот не может быть подвергнут процедура резервного копирования. У технологии есть вполне логичные и вполне понятные ограничения, касающиеся, в частности, изменения логической структуры базы данных, операции shrink, удаления файлов данных, операций в режиме nologging. Так же очевидно, что при включении flashback у нас вырастет нагрузка на дисковую подсистему на запись и вырастут требования к дисковому пространству области fra. На этом фоне примечательно выглядит еще одна возможность Oracle: создание guarantee restore point без включения flashback. В этом случае в базе данных создается некое подобие моментального снимка, а все изменения отслеживаются на уровне блоков данных. Причем если 1 блок данных будет изменен 10 раз, то база данных будет хранить всего 2 его состояния: на момент создания точки восстановления и последнее актуальное состояние. Очевидно, что такой вариант может быть более предпочтительным с точки зрения утилизации дисковых ресурсов, но менее гибким с точки зрения восстановления до любой точки в промежутке между настоящим временем и временем создания точки восстановления (при включенной опции flashback база данных сохранит в журнале все 10 промежуточных состояний значения блока данных, что позволит восстановить СУБД на любой момент времени от текущего до времени создания точки восстановления).

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

Следите за новостями. Берегите свои данные.

Оставить комментарий