База данных Oracle может становиться недоступной для использования по ряду причин, в том числе из-за аварий в системе, сбоев в сети, неполадок в носителе и природных катаклизмов. Главным для успешного восстановления, конечно же, является наличие тщательно протестированных резервных копий и регулярное проведение пробных процедур восстановления с использованием этих копий.
Восстановление базы данных является довольно сложной темой и испытание приемов восстановления на практике играет существенную роль в его успешном проведении. Новые технологии ретроспективного отката (Flashback) служат замечательной альтернативной нескольким традиционным технологиям восстановления более сильного действия, и потому ими нужно обязательно овладеть. В этой статье рассказывается о наиболее важных приемах восстановления Oracle, тем не менее, пользоваться предлагаемыми Oracle руководствами по резервному копированию и восстановлению и имитировать различные сценарии восстановления все равно не помешает.
В частности, в настоящей статье рассматриваются следующие вопросы.
- Виды неполадок с базой данных (неполадки на уровне системы, неполадки на уровне носителя и т.д.).
- Выполняемые автоматически процедуры восстановления после аварий и восстановления экземпляров и инициируемые пользователем процедуры восстановления носителя (последним в этой статье уделяется больше всего внимания).
- Выполнение восстановления с помощью утилиты RMAN (Recovery Manager — диспетчер восстановления, это предмет отдельной статьи).
- Предлагаемые в Oracle Database 11g и 12c новые технологии ретроспективного отката (Flashback).
Помимо неполадок с носителем могут также случаться повреждения блоков данных, чреватые возможной потерей данных. Существуют специальные меры, которые можно принимать для предотвращения повреждения данных, а также для спасения большинства непострадавших данных из уже поврежденных блоков с помощью специализированных пакетов поставляемых в составе Oracle. Об этих мерах тоже будет рассказываться ближе к концу данной статьи моего блога.
Восстановление — это процесс, допущение ошибок в котором может обходиться очень дорого и приводить к потере данных. Успешность его выполнения напрямую зависит от понимания связанных с резервным копированием и восстановлением концепций и знания того, какие приемы нужно применять для устранения различных видов неполадок с носителем. В самом конце этой статьи будет приведен ряд различных сценариев восстановления, иллюстрирующих, какие в общем случае шаги могут потребоваться при различных типах восстановления.
Типы неполадок с базой данных Oracle
Самой важной задачей администратора баз данных является охрана данных предприятия и позволение пользователям получать к ним доступ с как можно меньшим количеством перебоев. В недавней статье блогов говорилось о том, насколько важно иметь под рукой надлежащую стратегию по выполнению резервного копирования и восстановления. База данных может переставать работать по ряду причин, одни из которых связаны с механическими проблемами, а другие — с ошибками пользователей или природными катаклизмами, как описывается в следующих нескольких подразделах.
Неполадки в системе
Самым распространенным видом неполадок в системе являются неполадки, связанные с оборудованием. Может выйти из строя контроллер дисков или повредиться головка какого-нибудь диска. Могут перестать нормально работать какие-то из периферийных устройств или контроллеров системы. Может возникнуть проблема с центральным процессором в системе или оказаться, что микросхемы памяти являются дефектными. И, конечно же, всегда может произойти влекущий неполадки перебой с электропитанием, особенно если отсутствуют источники бесперебойного питания. Проблемы с программным обеспечением могут возникать в результате появления неполадок как на стороне операционной системы, так и на стороне сервера Oracle. Столкновение с неполадкой на сервере может завершаться мгновенным аварийным отказом базы данных, а с неполадкой в программном обеспечении среднего звена — выходом из строя сети или генерацией каких-то других проблем.
В случае если функционирует только один экземпляр и вся система внезапно выходит из строя, сделать на самом деле можно не особо много. При наличии жизненно важных систем, можно предотвращать их простой за счет применения состоящего из нескольких узлов кластера и тем самым избегать одиночной точки отказа. Oracle предлагает технологию RAC (Real Application Clusters — Кластеры реальных приложений), которая подразумевает запуск нескольких экземпляров с разных серверов, подключающихся к одной базе данных. В случае выхода какого-то одного узла или сервера из строя, остальные могут принимать на себя его обязанности в течение всего лишь нескольких секунд, безо всякого заметного перерыва в обслуживании. Вдобавок Oracle предлагает механизм Transparent Application Failover (Прозрачное переключение приложений), который можно использовать совместно с RAC для прозрачного переключения клиентов с одного сервера на другой.
Аварии в центре данных
Аварии в центре данных могут варьироваться от торнадо и пожаров до террористических атак. В блогах уже рассказывалось о технологии Oracle Data Guard, предусматривающей применение резервных баз данных (standby databases). Резервные базы данных обеспечивают хорошую защиту от подобных аварий. Благодаря пересылке всех изменений, которые вносятся в производственную базу данных, ее резервному дубликату по сети, в случае возникновения аварии организация может продолжать работу безо всяких перерывов, просто превратив дубликат базы данных в главную производственную базу данных, что не подразумевает никаких существенных перерывов в работе и потери данных.
Кроме того, с помощью технологии Oracle Streams поддерживается распределенная система баз данных, когда удаленная база данных может принимать управление от основной производственной системы в случае полного выхода той из строя.
Человеческие ошибки
Люди могут и действительно допускают ошибки. Администраторы баз данных или системные администраторы тоже люди и потому могут допускать критические ошибки, способные подвергать их базы данных опасности. Например, они могут случайно выполнять не то пакетное задание, приводящее к генерации бессмысленных или неправильных данных.
В случае ввода неправильных данных в таблицу или удаления каких-то данных по ошибке исправить проблему можно несколькими способами. Во-первых, можно воспользоваться предлагаемой Oracle функцией Flashback Query (ретроспективные запросы), которая позволяет запрашивать старые данные и заменять ими утраченные или неправильно введенные данные без всякого перевода базы данных в автономный режим. В блогах уже рассказывалось о различных функциях типа Flashback, действие которых основано на применении данных отката. В этом блоге будет рассказываться о еще двух функциях этого типа, а именно — Flashback Database (ретроспективный откат базы данных) и Flashback Drop (ретроспективный откат удаления), которые позволяют выполнять восстановление базы данных или таблицы без восстановления файлов данных.
Кроме того, можно использовать предлагаемую Oracle утилиту LogMiner для считывания содержимого журналов повторного выполнения и отмены внесенных в базу данных изменений, либо применять утилиты Data Pump Export и Data Pump Import для замены пострадавших таблиц, но такой способ чреват потерей некоторых данных.
Также можно выполнять процедуру восстановления до состояния на какой-то момент времени в прошлом (Point-In-Time Recovery — PITR) и восстанавливать базу данных или табличное пространство до состояния, в котором оно находилось до того, как произошла проблема. Новые функции типа Flashback, однако, в большинстве случаев являются более удобной альтернативой, в чем вы убедитесь, изучая настоящий блог.
Неполадки с носителями
Самыми серьезными в плане восстановления являются неполадки, связанные с проблемами в носителях. Повреждения, препятствующие выполнению чтения и записи дисков, считаются самыми опасными, и возможность приведения базы данных в актуальное состояние безо всякой безвозвратной потери данных при таких повреждениях полностью зависит от наличия доступа к резервным копиям базы данных и файлов журналов. Если файлы данных или управляющие файлы находятся на недоступном носителе, скорее всего, придется выполнять процедуру восстановления.
В некоторых ситуациях выполнять процедуру восстановления может быть необходимо и в отсутствие повреждений носителя, например, при допущении серьезной ошибки пользователем. При необходимости использовать резервную копию для восстановления файла данных или переводе файла в автономный режим с помощью параметра OFFLINE IMMEDIATE, процедуру восстановления потребуется выполнять на уровне носителя. Когда случается беда, критически важную роль начинают играть два фактора: объем данных, которые стали недоступными и которые необходимо заменить соответствующими данными из резервных копий, и количество времени, которое может уйти на осуществление этой замены.
Неполадки и восстановление данных
Как уже упоминалось ранее, отказ экземпляра не требует выполнения процедуры восстановления данных. Возникновение неполадки в сети или аварийное завершение фонового процесса Oracle либо же нехватка пространства могут приводить к временному прерыванию работы базы данных, но тоже не требуют процедуры восстановления данных.
Выполнять процедуру восстановления данных необходимо только тогда, когда причиной проблемы является неполадка с носителем или ошибка пользователя. Поэтому давайте рассмотрим, что собой представляют эти два типа критических неполадок.
- Неполадки с носителем. Неполадки с носителем возникают тогда, когда базе данных не удается считать данные из файла или записать данные в него. Подобное может происходить из-за случайного удаления, повреждения или перезаписывания файла. Механические проблемы наподобие аварийного отказа головок тоже могут приводить к возникновению неполадок с дисками. То, что будет происходить после возникновения неполадки с носителем, зависит от того, имеется ли в наличии второй экземпляр пострадавшего файла. Например, если пострадает файл журнала повторного выполнения, база данных будет продолжать функционировать без проблем, если была сделанная мультиплексированная копия этого файла. Если же, с другой стороны, пострадает файл данных, принадлежащий табличному пространству System, база данных будет немедленно завершать свою работу.
- Ошибки пользователей. Ошибки пользователей возникают тогда, когда пользователь вводит неправильные данные или случайно удаляет данные или целую таблицу. Для отмены последствий таких ошибок существует множество приемов.
Oracle предлагает несколько методов для устранения проблем, произошедших из-за неполадок с носителем и ошибок пользователей. Конечно, всегда можно воспользоваться соответствующими резервными копиями базы данных, но выполнение восстановления данных из резервных копий является далеко не единственным доступным решением. В зависимости от типа проблемы, которую требуются устранить, еще доступны следующие методы.
- Программа Data Recover Advisor (Советник по восстановлению данных). Эта программа выявляет неполадки, предлагает варианты для их устранения и может применять их после получения на то одобрения от администратора. Она предлагает как подлежащие выполнению вручную, так и автоматизированные варианты для устранения неполадок, и может определять, какой из них является наилучшим. Получать доступ к ней можно либо через командную строку RMAN, либо через интерфейс Enterprise Manager (Диспетчер предприятия). База данных автоматически обнаруживает неполадки и фиксирует их в автоматическом репозитории диагностики (Automatic Diagnostic Repository — ADR). Вдобавок можно выполнять заблаговременную проверку на предмет целостности данных или проверку на предмет наличия повреждений в блоках с помощью команды VALIDATE. Каким бы путем не выявлялась проблема — профилактической (proactive) или реактивной (reactive) проверкой — для устранения ее последствий в базе данных в первую очередь следует применять Data Recover Advisor.
- Функции типа Flashback. В число предлагаемых Oracle функций типа Flashback входят функции, помогающие просматривать предыдущие состояния данных, а также функции, имеющие отношение к резервному копированию и восстановлению данных. Действие всех функций этого типа, кроме Flashback Drop, основано на использовании данных отмены. В устранении неполадок, связанных с ошибками пользователей или логическим повреждением данных, в основном помогают следующие функции этого типа:
- Flashback Database — функция ретроспективного отката базы данных;
- Flashback Table — функция ретроспективного отката таблицы;
- Flashback Drop — функция ретроспективного отката удаления;
- Flashback Transaction Backout — функция ретроспективной отмены транзакций.
Процедура восстановление носителя (media recovery). Выполнение процедуры восстановления носителя является, пожалуй, самым радикальным способом устранения устойчивой неисправности. В случае потери какого-нибудь файла данных, например, нужно восстанавливать копию этого файла из резервных копий. Выполнение процедуры восстановления из резервной копии, однако, является только половиной дела, поскольку резервные копии содержат данные только на какой-то момент времени в прошлом. В зависимости от частоты проведения операций резервного копирования, срок давности резервных копий может составлять от нескольких дней до нескольких недель. Поэтому для обновления восстановленного файла далее обязательно потребуется выполнить процедуру восстановления базы данных, которая подразумевает обновление базы с применением данных из архивных и оперативных журналов повторного выполнения и обычно называется процедурой восстановления носителя. Существует несколько следующих разновидностей этой процедуры:
- процедура восстановления носителя на уровне блоков;
- процедура восстановления носителя на уровне файлов данных;
- процедура полного восстановления;
- процедура восстановления до состояния на какой-то момент времени в прошлом (Point-In-Time Recovery).
В этой статье рассматриваются все три главных метода устранения устойчивых неполадок в базе данных. Однако прежде чем приступать к их рассмотрению, сначала необходимо ознакомиться с основными понятиями, которые используются при восстановлении баз данных Oracle.
Процесс восстановления Oracle
В общем случае, процедуры восстановления базы данных Oracle можно поделить на процедуры восстановления после аварийного отказа (crash recovery) и процедуры восстановления экземпляра (instance recovery) с одной стороны и процедуры восстановления носителя (media recovery) — с другой. Давайте проясним отличия между двумя этими типами процедур восстановления.
Восстановление после аварийного отказа и восстановление экземпляра
Oracle автоматически выполняет процедуру восстановления после аварийного отказа в случае, когда отказывает какой-то один или все экземпляры, если используется RAC-кластер Oracle с несколькими экземплярами. Кроме того, Oracle приходится выполнять эту процедуру в случае завершения работы базы данных с помощью команды SHUTDOWN ABORT. Что касается процедуры восстановления экземпляра, то она очень похожа на процедуру восстановления после аварийного отказа, но только касается случаев, когда выживший экземпляр восстанавливает утратившие работоспособность экземпляры в RAC. Главное в процедурах восстановления после аварии и восстановления экземпляров состоит в том, что они не предусматривают использования во время восстановления ни резервных копий файлов данных, ни архивных журналов повторного выполнения. Для возврата базы данных в актуальное состояние применяются только текущие файлы данных и оперативные журналы повторного выполнения.
Эти процедуры состоят из двух следующих этапов.
- Этап наката (roll-forward step), который формально называется этапом восстановления кэша (cache recovery) и во время которого база данных применяет зафиксированные и незафиксированные данные в текущих оперативных журналах повторного выполнения к текущим оперативным файлам данных.
- Этап отката (rollback step), который формально называется этапом восстановления транзакций (transaction recovery) и во время которого база данных удаляет примененные на предыдущем этапе незафиксированные транзакции за счет использования данных из сегментов отката.
Как известно, при внезапном аварийном завершении работы базы данных на диск успевают записываться не все зафиксированные транзакции. Если база данных и журналы повторного выполнения имеют большие размеры, этап наката и отката может занимать много времени. За счет применения предлагаемой в Oracle функции Fast-Start Fault Recovery (Быстрое восстановление после сбоя), однако, можно значительно сокращать время простоя базы данных из-за сбоев в работе системе.
При восстановлении после аварии на этапе наката сначала с помощью журналов повторного выполнения выясняется, какие изменения необходимо применить к диску. Применение журналов повторного выполнения начинается с точки, которая в этих журналах называется адресом байта повторного выполнения контрольной точки потока (thread checkpoint redo byte address), т.е. с момента, когда была создана последняя контрольная точка до того, как случилась авария. Поскольку во время создания контрольной точки все содержащиеся в буферах данные обязательно записываются на диск, получается, что восстановлению подлежат только изменения, которые произошли после создания последней контрольной точки. Механизм Fast-Start Checkpointing (Создание контрольных точек для быстрого восстановления) обеспечивает частое выполнение записи необработанного содержимого буферов базы данных из кэша на диск процессом записи в базу данных (DBWn). Именно он и лежит в основе предлагаемой в Oracle функции Fast-Start Fault Recovery. Частое перемещение положения контрольной точки позволяет сводить к минимуму время, требуемое для восстановления после аварии. Oracle применяет для выполнения восстановления с использованием контрольных точек двухэтапную методику. На первом этапе определяется, какие из блоков в журналах повторного выполнения нуждаются в восстановлении, а на втором — применяются необходимые изменения.
Начиная с Oracle Database 10g, база данных автоматически выполняет настройку контрольных точек, принимая решение о том, когда можно записать необработанное содержимое буферов на диск с минимальным воздействием на производительность. От администратора баз данных требуется лишь указать желаемое время (в секундах), которое должно занимать восстановление после аварии, установив нужное значение для параметра FAST_START_MTTR_TARGET.
Максимальным значением, которое может указываться для этого параметра, является 3600 секунд (1 час), а по умолчанию для него используется значение 0. (В случае установки значения свыше 3600 секунд Oracle будет автоматически сбрасывать его до 3600 секунд.) Даже при установке очень большого значения для данного параметра механизм создания контрольных точек все равно по умолчанию включается. Целью автоматического процесса настройки контрольных точек является осуществление записи необработанного содержимого буфера и создания контрольных точек настолько часто, насколько возможно, без увеличения накладных расходов и неблагоприятного воздействия на производительность базы данных.
Следующий пример показывает, как установить параметр FAST_START_MTTR_TARGET так, чтобы восстановление после аварий занимало не более одной минуты:
SQL> ALTER DATABASE SET FAST_START_MTTR_TARGET=60;
На заметку! Значение для параметра FAST_START_MTTR_TARGET можно также задавать и в файле параметров инициализации.
При первом выполнении восстановления после аварии Oracle может и не уложиться в указанные в предыдущем примере желаемые 60 секунд, поскольку первоначально Oracle использует приблизительные показатели по скорости выполнения операций ввода-вывода в системе. Но Oracle постоянно следит за системой, замеряя настоящие показатели по скорости выполнения операций ввода-вывода, и со временем начинает использовать уже эту информацию для более точного подсчета времени восстановления. Каждые 30 секунд Oracle подсчитывает, сколько в текущий момент составляет среднее время восстановления работоспособности (Mean Time To Recover — MTTR), и помещает это значение в таблицу V$INSTANCE_RECOVERY, к которой можно легко выполнять запрос, как показано ниже, для просмотра текущего подсчитанного Oracle показателя MTTR и настройки значения FAST_START_MTTR_TARGET соответствующим образом:
SQL> SELECT recovery_estimated_ios, estimated_mttr, target_mttr
FROM v$instance_recovery;
RECOVERY_ESTIMATED_IOS ESTIMATED_MTTR TARGET_MTTR
-----------------------------------------------------------
994 20 52
SQL>
На заметку! Применение функции Fast-Start Fault Recovery может обеспечить уменьшение времени выполнения восстановления после аварий до менее чем одной минуты. Хотя некоторым кажется, что более частое создание контрольных точек чревато серьезным снижением производительности, исследования показали, что воздействие на производительность на самом деле весьма незначительно.
Более быстрый запуск экземпляра
При наличии очень больших областей SGA, запуск экземпляра порой может занимать довольно приличное количество времени. Раньше Oracle обычно дожидалась инициализации всего содержимого кэша буферов, прежде чем запускать экземпляр, что и составляло большую часть задержки. Теперь Oracle инициализирует лишь приблизительно около 10% содержимого кэша буферов, прежде чем запускать экземпляр и открывать базу данных. Остальная часть содержимого кэша буферов инициализируется процессом создания контрольной точки уже после открытия базы данных.
Восстановление носителя
В отличие от восстановления после аварийного отказа и восстановления экземпляра, восстановление носителя не выполняется автоматически: администратор базы данных должен обязательно инициировать эту процедуру. Для выполнения процедуры полного восстановления носителя требуется иметь четыре следующих вещи:
- полная резервная копия всех файлов данных;
- архивные журналы повторного выполнения, созданные с момента последнего проведения полного резервного копирования;
- копия управляющего файла;
- текущие оперативные журналы повторного выполнения.
Процедура восстановления носителя Oracle гарантирует восстановление данных с точностью до минуты, при условии наличия экземпляра недавней резервной копии и архивных журналов повторного выполнения. Архивные журналы представляют собой журналы транзакций и содержат весь ряд изменений, которые были внесены в базу данных с момента последнего резервного копирования. За счет использования архивных журналов повторного выполнения и содержимого оперативных журналов повторного выполнения базу данных можно возвращать к актуальному состоянию. О восстановлении баз данных после неполадок с носителем будет рассказываться в этой статье довольно много.
Удаление файла данных
Прежде чем начинать процесс полного восстановления носителя, сначала нужно перевести подлежащие восстановлению файлы в автономный режим. Удалять файл данных можно прямо из SQL*Plus с помощью команды DROP DATAFILE. При выполнении этой команды файл данных удаляется как из табличного пространства, так и из операционной системы. Ниже приведен пример ее использования:
SQL> ALTER TABLESPACE TEST DROP DATAFILE '/u01/app/oracle/test/test01.dbf';
Если файл данных, который необходимо удалить, является единственным файлом данных в табличном пространстве, нужно удалить само табличное пространство, потому что табличное пространство, в котором находится файл данных, тоже должно обязательно пребывать в оперативном режиме и быть доступным для чтения и записи.
Процедура RESTORE и процедура RECOVER
Использование резервных копий файлов данных и управляющих файлов для замены утраченных или поврежденных файлов данных и управляющих файлов называется процедурой RESTORE, а приведение файлов данных в актуальное состояние с помощью файлов их резервных копий и файлов архивных журналов повторного выполнения — процедурой RECOVERY.
Процесс восстановления носителя
Процесс восстановления носителя Oracle состоит из двух этапов: на первом этапе выполняется процедура RESTORE, во время которой файлы данных восстанавливаются из резервных копий и делаются доступными для Oracle, а на втором — процедура RECOVERY, во время которой файлы данных приводятся в актуальное состояние за счет применения файлов архивных и оперативных журналов повторного выполнения.
Второй этап состоит из двух подэтапов.
- На первом подэтапе выполняется восстановление кэша (или накат). В журнале повторного выполнения содержатся как зафиксированные, так и не зафиксированные изменения. Как известно, Oracle сначала выполняет запись данных в журналы повторного выполнения и только потом в файлы данных. При восстановлении более старых файлов из резервных копий для замены утраченных или поврежденных файлов, изменения, которые были внесены после последнего резервного копирования, в этих файлах отсутствуют. Процесс применения содержимого файлов архивных и оперативных журналов повторного выполнения для приведения файлов данных в актуальное состояние называется восстановлением кэша или накатом. По завершении этого процесса в файлах присутствуют все зафиксированные изменения, но вместе с ними также присутствуют и все не зафиксированные изменения из журналов повторного выполнения.
- На втором подэтапе выполняется восстановление транзакций (или откат). При применении к файлам данных содержимого журналов повторного выполнения происходит применение как зафиксированных, так и незафиксированных изменений. Поэтому далее должно выполняться удаление из файлов данных всех незафиксированных изменений. Для удаления этих не зафиксированных изменений Oracle использует созданные до изменения версии данных, которые хранятся в сегментах отката. Этот процесс удаления не зафиксированных изменений называется восстановлением транзакций или откатом. Oracle подвергает данные отката процедуре восстановления кэша, что приводит к повторной генерации сегментов отката из журнала повторного выполнения.
На заметку! В случае применения утилиты RMAN восстановление файлов данных еще может выполняться с помощью инкрементных резервных копий, которые представляют собой резервные копии, содержащие только изменения, внесенные после предыдущего резервного копирования. Об инкрементных резервных копиях RMAN более подробно рассказывалось в этой статье.
Открытое и закрытое восстановление носителя
Важно запомнить, что неполадка или даже авария вовсе не обязательно должна влиять на всю базу данных. Пользователи могут продолжать работать с большинством частей базы данных, пока отдельная часть восстанавливается с помощью резервных копий.
Открытым восстановлением (open recovery) называется восстановление, выполняемое во время того, как база данных остается открытой для пользователей. В автономный режим переводятся только пострадавшие файлы данных или табличные пространства. Работа базы данных может продолжаться обычным образом с прерыванием обслуживания лишь тех транзакций, которые касаются поврежденной части базы данных.
Закрытым восстановлением (closed recovery) называется восстановление, для выполнения которого база данных полностью закрывается. Такое восстановление выполняется только тогда, когда в восстановлении нуждается вся база данных или когда были повреждены системные файлы или файлы отмены (undo files).
Время, необходимое для восстановления
Время, которое будет уходить на выполнение восстановления, зависит от перечисленных ниже факторов.
- На каком носителе расположены архивные журналы повторного выполнения? Если они находятся на ленте, на выполнение восстановления будет уходить гораздо больше времени, чем когда они находятся на диске. Поэтому рекомендуется всегда хранить лишнюю копию журналов где-нибудь на диске.
- Используется ли механизм параллельного восстановления? Реализация этого механизма будет сокращать время, необходимое для восстановления базы данных.
- Требуется ли заменить диски сразу же или можно обойтись просто перемещением файлов данных в другое исправное место?
- Как выглядят оговоренные в контракте на обслуживание условия по замене и восстановлению частей на сервере? Некоторые компании оговаривают выполнение восстановления в течение всего лишь 45 минут после исходного звонка, а некоторые могут допускать его проведение в течение 24 часов. Администратору баз данных нужно обязательно знать и разбираться в особенностях подписанного компанией контракта с поставщиком системы.
- Насколько часто выполняются операции резервного копирования? Чем реже выполняются операции резервного копирования, тем больше журналов потребуется применять, и тем больше времени будет занимать восстановление.
Полное и неполное восстановление
В случае выхода из строя диска и, следовательно, возникновения необходимости в выполнении восстановления из резервных копий, естественно, потребуется провести полное восстановление данных вплоть до того момента, когда произошла проблема. В случае же возникновения необходимости в восстановлении базы данных из-за ошибок пользователей (например, после ввода неправильных данных), может оказаться достаточным просто удалить ошибки из базы данных за счет выполнения восстановления лишь до того момента, когда было произведено неправильное действие. Такое восстановление обычно называется неполным а, как будет показано позже, решение о том, до какого именно момента должно выполняться восстановление базы данных, принимается на основании различных критериев.
Полное восстановление (complete recovery) представляет собой процедуру восстановления без потери данных. При таком восстановлении все изменения в оперативных и архивных журналах повторного выполнения применяются к самой последней резервной копии базы данных, благодаря чему база данных приводится в состояние, соответствующее текущему моменту во времени. Полное восстановление может осуществляться как на уровне всей базы данных, так и на уровне отдельных табличных пространств или файлов данных.
Неполное восстановление (incomplete recovery) подразумевает некоторую потерю данных, поскольку восстановлению подвергается только часть из тех данных, которые существовали на момент возникновения проблемы в базе данных. То есть при таком восстановления к базе данных применяются лишь некоторые из записей архивных и текущих журналов. По завершении этого восстановления база данных имеет согласованный, но не соответствующий текущему моменту во времени вид. Причин для выполнения такого вида восстановления может быть несколько, в том числе ошибки пользователей, потеря необходимых файлов архивных журналов или потеря какого-нибудь оперативного журнала повторного выполнения. При выполнении неполного восстановления нужно всегда открывать базу данных после сбрасывания журналов повторного выполнения. Это, по сути, приводит к получению новой версии или новой инкарнации базы данных. Неполное восстановление может выполняться только на уровне всей базы данных, но не на уровне отдельных табличных пространств или файлов данных.
Во время как полного, так и не полного восстановления оставлять базу данных открытой для пользователей нельзя. При логическом повреждении одного или нескольких табличных пространств (например, из-за ввода неправильных данных), еще можно выполнять процедуру восстановления этих табличных пространства до состояния на определенный момент времени в прошлом (Tablespace Point-In-Time Recovery — TSPITR).
Из-за отсутствия необходимости в неполном восстановлении носителя на уровне всей базы данных, процесс восстановления будет проходить гораздо быстрее. Кроме того, на время восстановления не потребуется делать недоступной для пользователей всю базу данных. Процедуры TSPITR являются несколько громоздкими, поэтому вместо них сначала может быть лучше рассматривать вариант применения функций Flashback, наподобие Flashback Table или Flashback Drop.
Восстановление носителя на уровне блоков
Если повредилось лишь несколько блоков, а остальная часть файла данных исправна, лучше выполнять восстановление носителя на уровне блоков (block media recovery), а не восстановление всего файла данных. Выполнять восстановление носителя на уровне блоков можно только через утилиту RMAN. Даже в случае применения своих собственных приемов для резервного копирования и восстановления, выполнять такой вид восстановления через RMAN все равно можно, сначала с помощью команды CATALOG зарегистрировав резервные копии необходимых файлов данных и архивных журналов повторного выполнения в RMAN.
Приемы с восстановлением носителя и приемы без восстановления носителя
Большинство прежних приемов для восстановления представляло собой процедуры восстановления носителя на основе файлов (file-based media recoveries). Какое бы средство не применялось — утилита RMAN или пользовательские методы — процесс восстановления всегда подразумевал выполнение (с помощью процедур RESTORE и RECOVER) восстановления файлов данных, файлов архивных журналов повторного выполнения и управляющих файлов. В случае потери всей базы данных или всего файла данных из-за проблем с носителем, у администратора баз данных не было другого выхода, как использовать приемы восстановления на базе файлов. При попытке отменить ошибки пользователей или восстановить случайно удаленную таблицу, однако, применение этих традиционных приемов восстановления оказывалось чрезмерно тягостным и длительным по времени.
Поэтому за последние несколько лет компания Oracle разработала несколько не основанных на файлах приемов восстановления (no-file-based recovery techniques). В этих приемах основной акцент делается не на восстановлении файлов, а на использовании либо данных отката, либо журналов повторного выполнения, либо же новых журналов ретроспективных данных отката (Flashback) для восстановления утраченных объектов. Ниже приведен список приемов восстановления, не основанных на файлах.
- Функции типа Flashback. Функции Flashback позволяют восстанавливать удаленные таблицы и выполнять восстановление таблицы или базы данных до состояния, в котором она находилась на определенный момент времени в прошлом. В наших блогах уже рассказывалось о таких функциях этого типа, как Flashback Query, Flashback Versions Query, Flashback Transactions и Flashback Table, поскольку в ней обсуждались данные отмены, которые образуют основу для работы этих функций. В будущих статьях моего блога будут рассматриваться еще две важных функции этого типа — Flashback Drop и Flashback Database.
- Утилита LogMiner. Предлагаемая Oracle утилита LogMiner позволяет анализировать журналы повторного выполнения, как оперативные, так и архивные, и тем самым выявляться и отменять ошибочные изменения в базе данных.
- Утилиты Data Pump. Предлагаемые Oracle утилиты Data Pump Export и Data Pump Import тоже могут применяться в качестве альтернативных средств для восстановления утраченных объектов. Об этих утилитах более подробно рассказывалось в этой статье блогов.
Хотя традиционные приемы восстановления на базе файлов и служили надежной основой долгое время, теперь все-таки лучше рассматривать вариант применения вместо них альтернативных приемов везде, где это только возможно. Например, за счет применения функции Flashback Database можно возвращать файлы данных к тому состоянию, в котором они находились когда-то в прошлом, и тем самым, следовательно, достигать того же конечного результата, что и в случае применения традиционной процедуры PITR, но только гораздо быстрее, благодаря отсутствию необходимости в выполнении восстановления файлов данных из резервных копий и использованию меньшего объема данных повторного выполнения, чем при восстановлении носителя.
Снижение степени уязвимости
Никакой аспект работы администратора баз данных Oracle не является более ужасным (или даже пугающим), чем восстановление баз данных Oracle из резервной копии. Помимо приемов восстановления, наилучшим способом защиты системы является, в первую очередь, снижение степени ее уязвимости.
Большинство типичных ошибок, которые возникают изо дня в день, связано с оборудованием. Диски или отвечающие за их управление контроллеры выходят из строя довольно регулярно. Чем больше база данных (и, следовательно, количество используемых дисковых накопителей), тем больше вероятность того, что в один прекрасный день потребуется приглашать мастера для починки или замены неисправной детали. Поскольку хорошо известно, что вся дисковая система является уязвимой точкой, нужно обязательно обеспечивать в базе данных избыточность. Настройка системы с зеркальным отображением дисков или системы с конфигурацией RAID 5 или же и той и другой вместе позволит легко получить необходимую избыточность.
Наличие распределенной или резервной базы данных предоставит возможность проводить восстановление без заметного перерыва в работе в случае выхода из строя всего сайта. Без этого любая серьезная проблема на уровне производственного центра данных будет приводить к серьезному нарушению сроков работоспособности.
Хранение полного запасного набора где-нибудь на сервере тоже не помешает. В состав этого набора обязательно должны входит последние резервные копии базы данных, архивные журналы повторного выполнения, сделанные после создания этих резервных копий, и мультиплексированная копия файлов оперативных журналов повторного выполнения и управляющего файла. В него также могут входить и другие файлы Oracle, например, файлы init.ora, SPFILE, tnsnames.ora и listener.ora.
Главное для успешного восстановления — это следовать простому девизу “Будь готов!” и иметь в наличии необходимые тщательно (и недавно) проверенные резервные копии. Помимо этого нужно также четко представлять себе стратегию восстановления. Хотя и можно рыться в книжках или руководствах и, возможно, (в конечном итоге) вычислять правильную последовательность действий для выполнения той или иной связанной с администрированием баз данных задачи, поступать подобным образом в случае восстановления базы данных не рекомендуется по нескольким причинам.
- Во-первых, при таких обстоятельствах всегда возникает большое психологическое давление, связанное с необходимостью привести базу данных в рабочее состояние как можно быстрее.
- Во-вторых, обычный спокойный ритм работы нарушается довольно неожиданно и резко, и кабинет быстро превращается в самый настоящий штаб военных действий, переполненный расстроенными и разъяренными руководителями, начинать рыться в книгах при которых, согласитесь, не очень-то удобно.
- В-третьих, заблаговременное знание того, что потребуется сделать в каждой из возможных критических ситуаций, позволяет резервировать под это дело как можно больше времени.
- И, наконец, в-четвертых, восстановление базы данных является одной из тех областей, в которой принимаемые решения и выполняемые команды не всегда обратимы. Подобные обстоятельства напоминают улицу с односторонним движением и потому любые допускаемые в них из-за спешки или невежества ошибки могут обходиться очень дорого.
В настоящей статье рассматриваются лишь несколько основных приемов для восстановления баз данных. В руководствах Oracle таких приемов предлагается гораздо больше. Порой разновидности ситуаций восстановления, которые могут встречаться, приводят в замешательство. Однако наличие исправного набора резервных копий и использование базы данных в режиме ARCHIVELOG гарантирует наличие возможности выполнения восстановления после потери любого файла данных или управляющего файла. Единственной ситуацией, которая может оканчиваться потерей данных, является потеря файлов оперативных журналов повторного выполнения. Поэтому лучше всегда мультиплексировать такие файлы, а также зеркально отображать их, тогда вероятность потери каких-либо данных будет очень низкой, даже в случае возникновения серьезной проблемы с дисковыми накопителями. Но в случае недоступности всех дисков (даже зеркально отображенных или защищенных каким-то другим образом) придет самая настоящая беда и тогда спасет только наличие либо альтернативной базы данных, на которую можно было бы переключиться, либо находящейся за пределами сайта системы восстановления после аварий.
В рассматриваемых далее сценариях восстановления базы данных рассказывается только о том, как выполнять восстановление базы данных, функционирующей в режиме архивирования журналов (ARCHIVELOG). Объясняется это очень просто: почти все критически важные базы данных функционируют именно в таком режиме. В случае понимания процедур восстановления, описываемых в следующих разделах блога, выполнение восстановления базы данных, функционирующей в режиме NOARCHIVELOG, не составит большого труда.
