
- •Защита баз данных
- •Различные виды неисправностей
- •Авария системы и сервера
- •Потеря файла в результате ошибки пользователя, повреждения или сбоя диска
- •Природные и неприродные бедствия
- •Обзор алгоритмов защиты базы данных
- •Пример резервного копирования и восстановления
- •Введение в менеджер восстановлений
- •Каталог восстановления
- •Интерфейс командной строки менеджера восстановлений
- •Менеджер копирования — графический пользовательский интерфейс менеджера восстановлений
- •Журнал транзакций
- •Структура журнала транзакций
- •Компоненты регистрации и отказоустойчивость
- •Контрольные точки
- •Защита управляющего файла базы данных
- •Резервное копирование базы данных
- •Полные резервные копии
- •Открытые резервные копии баз данных
- •Закрытые резервные копии баз данных
- •Резервные копии табличных областей
- •Оперативные резервные копии табличных областей
- •Отключенные резервные копии табличных областей
- •Концепции резервного копирования в менеджере восстановлений
- •Резервные наборы
- •Полные и инкрементные резервные наборы файлов данных
- •Копии-образы
- •Теги резервного копирования
- •Поврежденные блоки файлов данных
- •Логические резервные копии базы данных
- •Утилита экспорта
- •Утилита импорта
- •Правильное использование утилит экспорта и импорта
- •Другие способы использования утилит экспорта и импорта
- •Восстановление базы данных
- •Этапы восстановления "откат вперед" и "откат назад"
- •Восстановление после аварии
- •Восстановление носителей- восстановление после повреждения файлов
- •Устранение причин неисправности аппаратуры
- •Воссоздание потерянных файлов данных
- •Монтирование необходимых групп архивного журнала
- •Восстановление с помощью менеджера восстановлений
- •Полное восстановление
- •Восстановление базы данных
- •Восстановление табличной области
- •Восстановление файла данных
- •Неполное восстановление
- •Восстановление по времени
- •Обеспечение дополнительной защиты
- •Дублирующие базы данных
- •Узлы устранения отказов и тиражирование данных
Менеджер копирования — графический пользовательский интерфейс менеджера восстановлений
В большинстве операционных систем не используется интерфейс командной строки менеджера восстановлений и не требуется вводить одиночные команды менеджера восстановлений. Вместо этого применяется графический пользовательский интерфейс менеджера восстановлений, например менеджер управления серверами/менеджер копирования. Утилиты, создаваемые третьими фирмами, также могут использовать менеджер восстановлений для выполнения алгоритмов резервного копирования и восстановления базы данных.
Теперь, когда получено общее представление о том, что такое менеджер восстановлений, рассмотрим подробно средства Oracle, используемые для защиты базы данных от потери информации. В следующем разделе рассказывается о журнале транзакций базы данных.
Журнал транзакций
Журнал транзакций (transaction log) базы данныхOracle, называемый также журналом повтора (redo log), —это важный компонент базы данных, который защищает результаты работы всех завершенных транзакций. Изменения, вносимые завершенными транзакциями, немедленно записываются в журнал транзакций. Если в результате аварии экземпляра, сбоя диска или по другой причине необходимо восстановить базу данных,Oracleво время соответствующей операции восстановления прочитывает журнал транзакций и повторяет работу всех завершенных транзакций, которая не была учтена в базе данных.
Структура журнала транзакций
Журнал транзакций базы данных — это группа файлов операционной системы, расположенных на хост-компьютере. Как показано на рис. 3, журнал транзакций базы данных состоит из двух или более групп регистрации. Совокупность групп регистрации называется оперативным журналом транзакций (online transaction log).
Каждая группа регистрации, или группа журнала (log group),представляет собой набор, состоящий из одного или нескольких идентичных файлов операционной системы, в которые заносятся записи завершенных транзакций. Во время запуска сервера процессLGWRвыбирает одну из групп журнала транзакций, а затем использует эту группу, чтобы начать запись элементов регистрации. Группа регистрации, в которую в данный момент процесс LGWR заносит записи, называется текущей группой регистрации. Размер группы регистрации неизменен, и поэтому, в конце концов, группа заполняется информацией. Когда процесс LGWR заполняет текущую группу регистрации,Oracleвыполняет операцию, называемую переключением регистрации (log switch).При этомOracleзакрывает текущую группу регистрации, открывает следующую и начинает запись элементов регистрации в новую текущую группу.
Чтобы оптимизировать регистрацию элементов повтора транзакций, Oracleиногда разрешает процессу LGWR записывать элементы повтора открытых транзакций, предвидя завершение транзакций. Поэтому в любой конкретный момент в журнале транзакций может находиться небольшое число изменений базы данных, внесенных незавершенными транзакциями.Oracleсоответствующим образом помечает такие элементы повтора. Если необходимо восстановить базу данных, сервер автоматически убирает из нее незавершенные изменения.
Чтобы разрешить восстановление файлов данных базы, необходимо установить конфигурацию сервера так, чтобы он постоянно архивировал группы регистрации после их заполнения. Работая в этом режиме после переключения регистрации, фоновый серверный процесс архивации (ARCH) архивирует группу, бывшую до того текущей, в виде файла на диске.Oracleименует каждую архивную группу регистрации уникальным номером последовательности регистрации (log sequence number).Последовательность групп регистрации, постоянно создаваемаяOracleс помощью архивирования групп регистрации по мере их заполнения, называется архивным журналом транзакций (archived transaction log).В большинстве баз данныхOracleгруппы журнала транзакций архивируются, чтобы обеспечить абсолютную защиту базы данных от сбоев носителей, - этот режим называется режимомARCHIVELOG,или работой с "разрешенным восстановлением носителей" ("media recovery enabled").Для защиты архивного журнала транзакций можно использовать менеджер восстановлений и с его помощью выполнять резервное копирование файлов архивного журнала в отключенное от системы место хранения информации, например на магнитную ленту. Ниже в этой главе будет более подробно рассказано о менеджере восстановлений и о том, как выполнять резервное копирование архивного журнала транзакций базы данных.
Если группы регистрации не архивируются, можно немного повысить производительность системы. Однако последствия могут быть весьма неприятными, так как в этом случае Oracleсможет защитить базу данных только при незначительных авариях системы, но не при более серьезных неисправностях, таких как сбой диска.
После того как Oracleзаполняет последнюю группу регистрации журнала транзакций, процессLGWRснова переключает регистрацию на первую группу и повторяет процесс в том же самом порядке, что и прежде. Когда для записи элементов регистрации группа используется повторно, процесс LGWR переписывает старые элементы группы. Если сервер сконфигурирован для архивирования групп регистрации после их заполнения, то элементы регистрации сохраняются как часть архивного журнала транзакций базы данных. Циклически используя группы регистрации журнала транзакций, сервер базы данныхOracleможет постоянно записывать элементы журнала транзакций в относительно небольшое и заранее определенное пространство диска.