Управление восстановлением БД

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

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

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

Резервное копирование БД

Современные СУБД содержат набор различных средств, позволяющих делать резервные копии базы данных, а также восстанавливать её в случае необходимости. Существует три стандартных способа резервного копирования БД: экспорт, автономное резервное копирование и оперативное резервное копирование.

Экспорт представляет собой логическое копирование БД, два остальных способа – физическое копирование файлов.

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

Логическое резервное копирование базы данных предполагает чтение её записей и внесение их в файл. Записи считываются независимо от их физического расположения. При этом происходит обращение, как к данным, так и к словарю данных. Можно экспортировать всю БД, конкретные подсхемы или конкретные таблицы. В процессе экспорта можно также решить, следует ли экспортировать связанную с таблицами информацию словаря данных, такую как привилегии, индексы, ограничения. Созданные в процессе экспорта файл будет содержать команды, необходимые для полного воссоздания всех выбранных для экспорта объектов. Экспортированные данные не обязательно должны быть импортированы в ту же самую базу данных или в туже схему. С помощью этого файла можно создать копию экспортированных объектов в другой схеме или в другой БД. При реализации импорта данных возможно определить – все данные будут импортированы или необходимая их часть.

В ходе операций физического резервного копирования файлы БД копируются независимо от их логического содержания. Эти копии называют резервными копиями файловой системы. Различают два типа физического копирования файлов – автономное (холодное копирование) и оперативное (горячее копирование). Автономное копирование выполняется при нормальной остановке БД. После её отключения копируются следующие файлы: все файлы данных; все управляющие файлы; все оперативные журналы и т.д. Получают полный образ БД на момент её останова. Все файлы впоследствии можно извлечь из резервной копии и база данных снова будет работать. Оперативное резервное копирование можно осуществлять для любой БД, работающей в открытом режиме, это необходимо для баз данных, остановка которых невозможна. Оперативное резервное копирование позволяет впоследствии осуществить полное восстановление информации с привязкой ко времени.

Способы восстановления БД

Одна из основных функций администратора БД – быть готовым к возможному отказу системы. В случае возникновения отказа база данных должна быть восстановлена быстро и с минимально возможными потерями. Процесс восстановления БД требует от АБД:

— определения, какие структуры базы данных затронуты и требуют восстановления;

— выполнения соответствующих шагов по восстановлению;

— рестарта экземпляра БД для восстановления его нормальной работоспособности;

— проверки, что в базе данных не остались некорректные данные, и действия пользователей не пропали.

Цель этих мероприятий – наиболее быстрый возврат к нормальной работе пользователей с БД. В то же время необходимо уберечь пользователей БД от любых проблем, связанных с возможными потерями и необходимостью дублирования работ по ведению данных.

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

Поскольку обработка данных в многопользовательских системах не может быть возобновлена точно с того места, где она была прервана, то существует возможность отойти назад до некоторой известной точки состояния БД и возобновить работу с БД с неё.

Наиболее простой стратегией является возможность восстановления базы данных из её копии, которая периодически делается администратором БД. Затем при возникновении сбоя база данных восстанавливается, и заново производятся все утерянные транзакции, например, осуществляется повторный ввод данных, не отраженных в ранее сделанной копии. Такая стратегия для баз данных с большим числом пользователей может и не позволить вернуть систему в то состояние, в котором она находилась до сбоя из—за того, что при параллельной работе трудно восстановить и синхронизовать все действия пользователей. Какой—то объем данных будет утрачен.

Существует ещё один подход к восстановлению БД. Он заключается в том, чтобы периодически делать копии базы данных и вести журнал всех изменений, произведенных в базе данных транзакциями со времени последнего копирования. Восстановление в случае сбоя может быть произведено одним из двух методов. Первый – база данных восстанавливается до известного (отраженного в копии) состояния, после чего выполняются все правильные транзакции согласно записям в журнале. Метод называют «откат вперед» (rolling forward). Второй метод – в случае сбоя отменяются все ошибочные транзакции, затем запускаются правильные транзакции, которые выполнялись в момент сбоя – «откат назад», (rolling back). Для восстановления данных любым из этих методом требуется ведение журнала результатов транзакций. Современные СУБД имеют такие средства. Журнал транзакций позволяет сохранять действия, произведенных с данными в хронологическом порядке — прежде чем транзакция будет выполнена, она будет записана в журнал. В случае сбоя журнал используется как для отмены, так и для выполнения заданных транзакций. Журнал транзакций рекомендуется размещать на отдельном устройстве, что дает возможность повысить производительность и надежность системы баз данных:

— в случае потери работоспособности носителя данных сохраняется возможность создания резервной копии журнала транзакций;

— повышается скорость записи в журнал транзакций, так как операции ввода/вывода, разделенные между двумя устройствами, выполняются быстрее;

— рост объема журнала транзакций не понизит общую производительность системы;

— создание архивных копий журнала транзакций и данных происходит быстрее, поскольку они создаются отдельно друг от друга.

Размеры журнала транзакций варьируются в зависимости от объема модифицируемых данных и частоты создания архивных копий. Как правило, выделяют от 10 до 25% места, зарезервированного для данных.

Запись действий, производимых тем или иным пользователем БД, может вестись также администратором БД и другими способами, например, посредством использования различных триггеров.

Управление СУБД

К функциям, которые выполняет администратор БД, относятся также сбор и анализ статистики производительности работы СУБД, управление этой производительностью.

Производительность CУБД зависит от многих факторов – от используемой сервером БД операционной системы, от выделенных системных ресурсов, от параметров настройки ядра СУБД, от структуры запросов клиентских приложений к БД (например, производительность повышается при преимущественном использовании простых запросов, хранимых процедур, триггеров) и др.

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

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

Вопросы проектирования приложений БД