Oracle для профессионалов
Архивный журнал повторного выполнения
База данных Oracle может работать в двух режимах — NOARCHIVELOG
и ARCHIVELOG. Я считаю, что система, используемая в производственных условиях, обязательно должна работать в режиме ARCHIVELOG. Если база данных не работает в режиме ARCHIVELOG, данные рано или поздно будут потеряны. Работать в режиме NOARCHIVELOG можно только в среде разработки или тестирования.
Эти режимы отличаются тем, что происходит с файлом журнала повторного выполнения до того как сервер Oracle его перепишет. Сохранять ли копию информации повторного выполнения или разрешить серверу Oracle переписать ее, потеряв при этом навсегда — очень важный вопрос. Если не сохранить этот файл, мы не сможем восстановить данные с резервной копии до текущего момента. Предположим, резервное копирование выполняется раз в неделю, по субботам. В пятницу вечером, после того как за неделю было сгенерировано несколько сотен журналов повторного выполнения, происходит сбой диска. Если база данных не работала в режиме ARCHIVELOG, остается только два варианта дальнейших действий.
Оба варианта непривлекательны, поскольку приводят к потере данных. Работая же в режиме ARCHIVELOG, достаточно найти другой диск и восстановить на него соответствующие файлы с субботней резервной копии. Затем применить к ним архивные журналы повторного выполнения и, наконец, — оперативные журналы повторного выполнения (то есть повторить все накопленные за неделю транзакции в режиме быстрого наката). При этом ничего не теряется. Данные восстанавливаются на момент сбоя.
Часто приходится слышать, что в производственных системах режим ARCHIVELOG не нужен. Это глубочайшее заблуждение. Если не хотите в один момент потерять данные, сервер должен работать в режиме ARCHIVELOG. "Мы используем дисковый массив RAID-5 и абсолютно защищены" — вот типичное оправдание. Я сталкивался с ситуациями, когда по вине изготовителя все пять дисков массива одновременно останавливались. Я видел поврежденные аппаратным контроллером файлы данных, которые в поврежденном виде надежно защищались дисковым массивом. Если имеется резервная копия данных на момент, предшествующий сбою оборудования, и архивы не повреждены, — восстановление возможно. Поэтому нет разумных оснований для того, чтобы не использовать режим ARCHIVELOG в системе, где данные представляют хоть какую-нибудь ценность. Производительность — не основание. При правильной настройке на архивирование расходуется незначительное количество ресурсов системы. Это, а также тот факт, что быстро работающая система, в которой данные теряются, — бесполезна, заставляет сделать вывод, что, даже если бы архивирование журналов замедляло работу системы в два раза, оно в любом случае должно выполняться.
Не поддавайтесь ни на какие уговоры и не отказывайтесь от режима ARCHIVELOG. Вы потратили много времени на разработку приложения, поэтому надо, чтобы пользователи ему доверяли. О доверии можно забыть, если их данные будут потеряны.
Итак, мы рассмотрели основные типы файлов, используемых сервером Oracle: от небольших файлов параметров инициализации (без которых не удастся даже запустить экземпляр) до принципиально важных файлов журнала повторного выполнения и файлов данных. Обсудили структуры хранения данных в Oracle: от табличных пространств, сегментов и экстентов до блоков базы данных — наименьшей единицы хранения. Была описана обработка контрольной точки в базе данных и даже (несколько преждевременно) затронута работа физических процессов или потоков, составляющих экземпляр Oracle. В последующих разделах этой главы мы более детально рассмотрим эти процессы и структуры памяти.
