Защита БД от сбоев

Возможно, наиболее важным свойством коммерческих СУБД является поддержка ими восстановления после сбоев.

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

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

Существует множество потенциальных причин сбоев в работе БД.

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

2. Аварийный отказ программного обеспечения сервера БД. Этот сбой не должен происходить вообще. Важной характеристикой коммерческого сервера БД является требование невозможности катастрофического сбоя без наличия внешней причины. Результат тот же, что и в случае 1.

3. Аварийный отказ компьютера клиента БД. Состояние прил кли­ента будет потеряно, а все открытые тран-ии будут остановлены. Операции сервера могут быть нарушены, вследствие блокировок, удерживаемых неактив­ными тран-ями.

4. Отказ клиентского программного обеспечения. Этот сбой аналогичен сбою 3, за исключением того, что исполняющий клиентскую программу компьютер про­должает работать и может проинформировать сервер БД о произо­шедшем отказе программного обеспечения клиента.

5. Сбои в сетевом соединении между клиентом и сервером. Этот сбой похож на сбой 3 тем, что клиентский компьютер становится недоступен, и его тран-ии ос­танавливаются. Основное различие в том, что клиентский компьютер может появиться снова в любой момент времени.

6. Тран-я выполняет операцию отката. Тран-я по своей инициативе от­менила свое выполнение, и сделанные ею обновления должны быть удалены из БД.

7. Тран-я выполняет неразрешенную операцию. Менеджер тран-ий обнаружива­ет, что тран-я нарушила некоторый протокол. Сервер должен обладать воз­можностью прервать транзакцию и восстановить систему посредством отката.

8. Взаимная блокировка двух или более тран-ий. Если сервер обнаруживает со­стояние взаимной блокировки, он должен прервать одну или несколько тран-ий, чтобы разорвать взаимную блокировку. Блокировки, удерживаемые на­ходящимися в состоянии взаимной блокировки тран-ями, могут оказывать влияние на выполнение других тран-ий.

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

10. Повреждение хранящихся на диске данных. Ошибка аппаратного обеспечения, приводящая к недоступности некоторой части информации БД.

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

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

Дата добавления: 2015-05-09