Госэкзамен. Кафедра 29 / Ответы на билеты / Базы данных / Копирование и восстановление баз данных (7)

Копирование и восстановление баз данных

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

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

При выполнении резервного копирования базы данных предполагается, что она находится в согласованном состоянии, т. е. все зафиксированные обновления базы данных не только занесены в журнал, но и записаны также в таблицы базы данных. При реализации резервного копирования в режиме on-line возникает проблема: чтобы резервные копии оказались согласованными, после того как достигнута точка согласованного состояния базы данных и начинается резервное копирование, все обновления базы данных должны выполняться без обновления таблиц самой базы до тех пор, пока не завершится ее полное копирование. Большинство основных СУБД обеспечивают возможность резервного копирования в режиме on-line.

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

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

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

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

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

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

Варианты аварий:

1. нарушение целостности базы данных при окончании транзакции. Традиционное решение - откат транзакции.

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

3. Наконец, третий случай - авария внешнего носителя базы данных. Традиционное решение - переписать на исправный внешний носитель архивную копию базы данных (конечно, нужно ее иметь), после чего повторить операции всех транзакаций, которые были выполнены после архивации, а затем выполнить откат всех транзакций, не закончившихся к моменту аварии.

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

На примере Oracle.

Журнал транзакций – транзакции, кот. Заверешены, но не лежащие в БД.

ROLLBACK сегменты – прежнее состояние таблиц для незаверешенных транзакций.

Архивные файлы – информация из журнала транзакций (заполненного).

Если сбой, то Oracle по состоянию control-файла определяет, что треб. восстановление БД. Те транзакции, кот. В LOG-файле прогоняются повторно и кладутся в БД. Если требуется, то Oracle берет у архивных файлов и повторяет выполнение. Это прокрутка вперед. Из ROLLBACK транзакции откатываются назад.