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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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