Сбои и Восстановление

Рубрика: Oracle

Здравствуйте, уважаемые посетители сайта okITgo.ru! Продолжая тему бэкапа и восстановления, хотел бы подробнее остановиться на типичных сбоях и восстановлении, которое необходимо для ликвидации последствий того или иного сбоя, аварии, краха экземпляра и т.п. При планировании вашей стратегии бэкапа и восстановления Вы должны попытаться предвидеть ошибки, которые возникнут, и обеспечить создание бэкапов, необходимых для восстановления от этих ошибок. Тогда как существует несколько типов проблем, которые могут прервать нормальную работу базы данных Oracle или повлиять на операции ввода/вывода, только два из них требуют вмешательства DBA и восстановления носителя: сбой носителя и ошибки пользователя. Аварии экземпляра, проблемы с сетью, сбои фоновых процессов бд Oracle и сбои из-за выполнения операторов (к примеру, исчерпание некоторого ресурса, такого как свободное пространство в файле данных) могут потребовать вмешательства DBA, и даже могут вызвать крах экземпляра базы, но вообщем они не вызывают потери информации или необходимости восстанавливаться из бэкапа.


Данная статья раскрывает следующие темы:

Сбой Носителя

Работа базы после сбоя носителя онлайн журналов изменений или контрольных файлов зависит от того, защищен ли онлайн журнал изменений или контрольный файл мультиплексированием (multiplexing), что собственно рекомендуется. Когда онлайн журнал обновлений или контрольный файл мультиплексированы, несолько копий этих файлов существуют в системе. Мультиплексированные файлы следует хранить на разныз дисках.

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

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

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

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

Если экземпляр не может писать в файл данных табличного пространства SYSTEM, табличного пространства отката (undo) (если бд в режиме автоматического управления откатом (automatic undo management mode), что является предпочтительным выбором в Релизе 10g), или в файл данных табличного пространства, содержащего активные сегменты отката (при ручном режиме управления откатом (manual undo management mode)), то база генерирует ошибку и завершает экземпляр. Все файлы табличного пространства SYSTEM и все файлы данных, содержащие сегменты отката должны находиться в режиме онлайн для правильной работы базы данных.

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

В режиме ARCHIVELOG база данных записывает ошибку в файл трассировки писателя базы и переводит файл данных, при попытке записи в который возникла ошибка, в оффлайн-режим. (Все другие файлы данных в табличном пространстве, содержащем этот файл данных, остаются в режиме онлайн.) Вы можете затем исправить причину ошибки, а затем реставрировать и восстановить данное табличное пространство.

В режиме NOARCHIVELOG фоновый процесс-писатель бд (database writer background process или DBWR) прекращается и происходит сбой экземпляра, причина проблемы определяет необходимое решение. Если проблема временная (например, контроллер диска был выключен), то обычно достаточно выполнить аварийное восстановление, используя файлы онлайн журналов изменений. В таких ситуациях экземпляр может быть перезагружен без прибегания к восстановлению носителя. Однако, если файл данных поврежден, Вы должны реставрировать согласованный бэкап базы целиком.

Ошибки Пользователя

Как правило, пользовательские ошибки, такие как удаление таблицы или удаление строк из таблицы, требуют одно из следующих решений:

  • Реимпорт удаленного объекта, если существует подходящий файл экспорта, или этот объект по-прежнему доступен в запасной (standby) бд
  • Выполнение восстановления табличного пространства на момент времени (TSPITR) одного или нескольких табличных пространств
  • Повторный ввод потерянной информации вручную, если существует их запись
  • Возврат бд к прошлому состоянию, используя восстановление базы на момент времени
  • Использование ретроспективных возможностей бд Oracle для восстановления от логического повреждения путем возврата поврежденных объектов в прошлое состояние

Опции восстановления, доступные для Вас, будут функцией вашей стратегии бэкапа. К примеру, если база работает в режиме NOARCHIVELOG, то у Вас ограниченные возможности восстановления на момент времени.

Спасибо за внимание! До новых встреч на страницах сайта okITgo.ru.

Рубрика: Oracle