Способы восстановления и реорганизации

 

Способы реорганизации БД

 

Реорганизация БД — это изменение логической, концептуальной или физической схемы базы данных [1, 11].

Реорганизация происходит при следующих событиях:

— изменение связей между объектами;

— добавление новых типов данных;

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

— создание новой БД на основе уже имеющихся БД, например при слиянии компаний и необходимости объединить БД, поддерживаемые различными СУБД;

— увеличение объема данных, что вызывает необходимость переноса данных на другие физические носители или системы ввода-вывода;

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

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

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

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

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

Реорганизация, параллельная с эксплуатацией. В данной стратегии не требуется запуск ядра СУБД в автономном режиме. При этом пользователь имеет доступ к реорганизованной части БД, в то время как один или более процессов реорганизации осуществляют модификацию БД либо на месте, либо путем загрузки и перезагрузки. Такая реорганизация требует осторожности со стороны АБД.

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

 

Восстановление БД

 

Восстановление БД — это процесс возвращения БД в состояние, утраченное в результате сбоя или отказа [1]. Существует множество различных сбоев и отказов, способных повлиять на функционирование БД. Каждый из них может привести к потерям данных или их целостности. Соответственно для каждого из них требуются определенные виды восстановления данных. Можно сказать, что восстановление БД — это защита от потерь методом создания резервных копий и восстановления данных по ним.

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

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

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

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

С учетом перечисленных причин возникновения отказов выделяют три типа восстановления БД.