Поддержка автоматического восстановления

Восстановление при повреждении жесткого диска

Восстановление посредством отката

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

Хотя зафиксированные тран-ии могут быть отменены посредством прокрутки вперед, часто более эффективно выполнить откат зафиксированных тран-ий. Система должна хранить журнал отмены (undo log), содержащий исходный образ каждого обновленного значения. Откат начинается с текущего состояния и отменяет все обновления в обратном порядке до достижения желаемого состояния.

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

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

Если нет возможности набор страниц диска считать правильно, возможно, удастся восстановить значения из кэша диска. Если же нет, необходимо определить, какие объекты БД хранятся в этой области, и использовать журналы тран-ий для воссоздания этих значений.

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

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

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

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

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