Продолжаем изучать основные свойства СУБД Oracle.
Предлагаю вам мой перевод части документации Oracle Database Concepts 10g Release 2 (10.2) B14220-02.
Обзор возможностей резервного копирования и восстановления
В каждой системе управления базой данных существует возможность аппаратного или программного сбоя. Если сбой произошел, то базу данных необходимо
восстановить. Восстановление может считаться законченным, если гарантируется, что результаты всех завершенных трансакций отражены в восстановленной
базе и база переведена в нормальный режим работы.
Oracle предлагает разнообразные механизмы для следующих ситуаций:
Восстановление базы данных после разнотипных сбоев.
Гибкие операции восстановления, подходящие для разных ситуаций.
Доступность данных во время резервного копирования и восстановления, таким образом, пользователи могут продолжать работу с базой.
Типы сбоев
Некоторые обстоятельства могут остановить работу базы данных Oracle. Наиболее часто встречающиеся типы сбоев описаны в следующей таблице.
Сбой
Описание
Ошибка пользователя
Зарос восстановить базу данных на момент, предшествующий сбою. Например, пользователь мог случайно удалить таблицу. Чтобы обеспечить
возможность восстановления после ошибки пользователя и удовлетворить другие уникальные требования к восстановлению, Oracle выполняет
восстановление до определенной точки. Например, если пользователь случайно удалил таблицу, база данных может быть возвращена в состояние,
предшествующее удалению таблицы.
Сбой запроса
Случается, если имеет место сбой обработки запроса в программе. Если происходит сбой запроса, все действия запроса откатываются и управление
возвращается пользователю.
Сбой процесса
Это результат сбоя в пользовательском процессе, установившем соединение с Oracle, например ненормальный разрыв соединения или аварийное
завершение работы. Фоновый процесс PMON автоматически определяет сбой пользовательского процесса, откатывает все незавершенные трансакции и
освобождает занятые ресурсы.
Сбой инстанции
Случается, если по какой-либо причине инстанция прерывает свою работу. Сбой инстанции может быть следствием аппаратной проблемы, например
отключение электропитания, или программного сбоя, например сбой операционной системы. При сбои инстанции данные в буферах SGA не сохраняются
в файлы данных (datafiles).
После сбоя Oracle автоматически выполняет операцию восстановления. Если произошел сбой одной из инстанций RAC, то другие инстанции
восстанавливают файл отката для сбойной инстанции. В одиночной инстанции или при одновременном сбое всех инстанций RAC, Oracle автоматически
выполняет восстановление при перезапуске базы.
Сбой носителя (диска)
Сбой может произойти во время операций чтения/записи файла на диск. Типичный пример - сбой головки диска, ставший причиной потери всех файлов
на диске.
Различные файлы могут быть испорчены в следствии этого сбоя, файлы данных, файлы отката, управляющие файлы. Кроме того, т.к. инстанция базы
данных не сможет продолжать нормальную работу, данные из буферов SGA, не смогут быть записаны на диск.
Сбой диска требует восстановления потерянных файлов и выполнения процедуры восстановления носителя. В отличии от восстановления инстанции,
восстановление носителя должно быть инициировано пользователем. Процедура восстановления носителя возвращает файлы данных в состояние,
предшествующее сбою диска, кроме того, в них записываются данные завершенных трансакций, находившиеся в памяти во время сбоя.
Структуры, используемые для восстановления
Oracle использует несколько структур для реализации полного восстановления после сбоя инстанции или диска: redo log (лог отката), control file
(управляющий файл), database backups (резервные копии базы).
Redo Log
Это набор файлов, которые защищают изменяемые данные, находящиеся в памяти, и которые еще не написаны в файлы данных. Redo log может состоять из
online redo (логов "на лету") и archived redo log (архивные логи).
Замечание: т.к. online log делается всегда во время работы базы (в отличие от архивных логов), он часто называется просто redo log (файл отката).
Online redo log это набор из двух или большего количества online redo файлов, в которые записываются все изменения, сделанные в базе данных,
включая незаконченные и законченные транзакции. Данные отката временно сохраняются в буфер отката SGA, фоновый процесс LGWR последовательно
записывает эти данные в online redo log файлы. LGWR непрерывно сохраняет данные отката. Кроме того, как только пользователь завершает
транзакцию LGWR сохраняет измененные записи.
Опционально, заполненные файлы отката могут быть в ручную или автоматически архивированы перед повторным использованием, таким образом создаются
archived redo logs (архивированные файлы отката).
Для включения или отключения архивирования, установите один из следующих режимов базы данных:
ArchiveLog. Заполненные файлы отката архивируются перед повторным циклическим использованием.
NoArchiveLog. Заполненные файлы отката не архивируются.
Если установлен режим ArchiveLog, база данных может быть полностью восстановлена после сбоя инстанции или носителя. Кроме того, во время работы базы
может быть сделана резервная копия. Ведение архивированных файлов отката требует дополнительных административных операций.
Если база данных работает в NoArchiveLog, то база данных может быть восстановлена только в случае сбоя инстанции, но не носителя. Кроме того,
резервная копия базы данных может быть сделана только после полного закрытия базы. Поскольку архивирование файлов отката не делается, дополнительные
административные операции не требуются.
Undo Records (записи отката)
Записи отката сохраняются в табличные пространства отката. Oracle использует данные отката в различных целях, включая доступ к предыдущей версии
данных, измененных в незавершенной транзакции. Чтобы откатить незавершенную транзакцию, Oracle использует информацию, сохранную в redo log, после
чего поднимает данные из "Записей отката".
Control Files (управляющие файлы)
Управляющие файлы хранят информацию о структуре базы данных, номер текущего файла записывается фоновым процессом LGWR. Информация, хранящаяся в
управляющих файлах, используется для управления процессом восстановления.
Database Backups (резервные копии базы данных)
Сбой носителя может стать причиной физического повреждения файлов. В этом случае для восстановления данных потребуется более старая версия файлов.
Для создания резервной копии файлов можете воспользоваться утилитами операционной системы или средством Recovery Manager (RMAN).
RMAN - это утилита Oracle, которая управляет операциями резервного копирования и восстановления, создает копии файлов базы данных
(файлы данных, управляющие файлы, архивированные логии отката).