Восстановление баз данных. Восстановление баз данных основные алгоритмы и этапы
 Скачать 16.57 Kb.
|
|
Тема: Восстановление баз данных: основные алгоритмы и этапы В ходе операций физического резервного копирования файлы БД копируются независимо от их логического содержания. Эти копии называют резервными копиями файловой системы. Различают два типа физического копирования файлов – автономное (холодное копирование) и оперативное (горячее копирование). Автономное копирование выполняется при нормальной остановке БД. После её отключения копируются следующие файлы: все файлы данных; все управляющие файлы; все оперативные журналы и т.д. Получают полный образ БД на момент её останова. Все файлы впоследствии можно извлечь из резервной копии и база данных снова будет работать. Оперативное резервное копирование можно осуществлять для любой БД, работающей в открытом режиме, это необходимо для баз данных, остановка которых невозможна. Оперативное резервное копирование позволяет впоследствии осуществить полное восстановление информации с привязкой ко времени. Способы восстановления БД Одна из основных функций администратора БД – быть готовым к возможному отказу системы. В случае возникновения отказа база данных должна быть восстановлена быстро и с минимально возможными потерями. Процесс восстановления БД требует от АБД: — определения, какие структуры базы данных затронуты и требуют восстановления; — выполнения соответствующих шагов по восстановлению; — рестарта экземпляра БД для восстановления его нормальной работоспособности; — проверки, что в базе данных не остались некорректные данные, и действия пользователей не пропали. Цель этих мероприятий – наиболее быстрый возврат к нормальной работе пользователей с БД. В то же время необходимо уберечь пользователей БД от любых проблем, связанных с возможными потерями и необходимостью дублирования работ по ведению данных. Процесс восстановления зависит от типа отказа и размеров части базы, на которую отказ повлиял. Администратор БД должен предвидеть любой тип отказа и иметь соответствующую стратегию восстановления. При выборе стратегии восстановления необходимо исходить из альтернативы, связанной со степенью "восстановимости" и затратами на защиту БД. В общем случае, чем больше гарантия защиты данных, тем больше затраты на ее реализацию со стороны АБД. Поскольку обработка данных в многопользовательских системах не может быть возобновлена точно с того места, где она была прервана, то существует возможность отойти назад до некоторой известной точки состояния БД и возобновить работу с БД с неё. Наиболее простой стратегией является возможность восстановления базы данных из её копии, которая периодически делается администратором БД. Затем при возникновении сбоя база данных восстанавливается, и заново производятся все утерянные транзакции, например, осуществляется повторный ввод данных, не отраженных в ранее сделанной копии. Такая стратегия для баз данных с большим числом пользователей может и не позволить вернуть систему в то состояние, в котором она находилась до сбоя из-за того, что при параллельной работе трудно восстановить и синхронизовать все действия пользователей. Какой-то объем данных будет утрачен. Существует ещё один подход к восстановлению БД. Он заключается в том, чтобы периодически делать копии базы данных и вести журнал всех изменений, произведенных в базе данных транзакциями со времени последнего копирования. Восстановление в случае сбоя может быть произведено одним из двух методов. Первый – база данных восстанавливается до известного (отраженного в копии) состояния, после чего выполняются все правильные транзакции согласно записям в журнале. Метод называют «откат вперед» (rolling forward). Второй метод – в случае сбоя отменяются все ошибочные транзакции, затем запускаются правильные транзакции, которые выполнялись в момент сбоя – «откат назад», (rolling back). Для восстановления данных любым из этих методом требуется ведение журнала результатов транзакций. Современные СУБД имеют такие средства. Журнал транзакций позволяет сохранять действия, произведенных с данными в хронологическом порядке – прежде чем транзакция будет выполнена, она будет записана в журнал. В случае сбоя журнал используется как для отмены, так и для выполнения заданных транзакций. Журнал транзакций рекомендуется размещать на отдельном устройстве, что дает возможность повысить производительность и надежность системы баз данных: — в случае потери работоспособности носителя данных сохраняется возможность создания резервной копии журнала транзакций; — повышается скорость записи в журнал транзакций, так как операции ввода/вывода, разделенные между двумя устройствами, выполняются быстрее; — рост объема журнала транзакций не понизит общую производительность системы; — создание архивных копий журнала транзакций и данных происходит быстрее, поскольку они создаются отдельно друг от друга. Размеры журнала транзакций варьируются в зависимости от объема модифицируемых данных и частоты создания архивных копий. Как правило, выделяют от 10 до 25% места, зарезервированного для данных. Запись действий, производимых тем или иным пользователем БД, может вестись также администратором БД и другими способами, например, посредством использования различных триггеров. |