ков базы данных (Database Block Writer - DBWn). Буферный кэш и процесс DBWn подробно рассматриваются ниже, но мы все равно забегаем вперед, так что имеет смысл поговорить о них.

В буферном кэше базы данных временно хранятся блоки базы данных. Это структура в области SGA разделяемой памяти экземпляра Oracle. При чтении блоки запоминаются в этом кэше (предполагается, что в дальнейшем их не придется читать с диска). Буферный кэш - первое и основное средство настройки производительности сервера. Он существует исключительно для ускорения очень медленного процесса ввода/вывода. При изменении блока путем обновления одной из его строк изменения выполняются в памяти, в блоках буферного кэша. Информация, достаточная для повторного выполнения этого изменения, записывается в буфер журнала повторного выполнения - еще одну структуру данных в области SGA. При фиксации изменений с помощью оператора COMMIT сервер Oracle не записывает на диск все измененные блоки в области SGA. Он только записывает в активные журналы повторного выполнения содержимое буфера журнала повторного выполнения. Пока измененный блок находится в кэше, а не на диске, содержимое соответствующего активного журнала может быть использовано в случае сбоя экземпляра. Если сразу после фиксации изменения отключится питание, содержимое буферного кэша пропадет.

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

Тут и вступает в игру процесс DBWn. Это фоновый процесс сервера Oracle, отвечающий за освобождение буферного кэша при заполнении и обработку контрольных точек. Обработка контрольной точки состоит в сбросе грязных (измененных) блоков из буферного кэша на диск. Сервер Oracle делает это автоматически, в фоновом режиме. Обработка контрольной точки может быть вызвана многими событиями, но чаще всего - переключением журнала повторного выполнения. При заполнении файла журнала 1, перед переходом на файл журнала 2, сервер Oracle инициирует обработку контрольной точки. В этот момент процесс DBWn начинает сбрасывать на диск все грязные блоки, защищенные файлом журнала I. Пока процесс DBWn не сбросит все блоки, защищаемые этим файлом, сервер Oracle не сможет его повторно использовать. Если попытаться использовать его прежде, чем процесс DBWn завершит обработку контрольной точки, в журнал сообщений (alert log) будет выдано следующее сообщение:

Thread 1 cannot allocate new log, sequence 66 Checkpoint not complete

Current log# 2 seq# 65 mem# 0: C:\ORACLE\ORADATA\TKYTE816\REDO02.LOG

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

чи этого сообщения обработка изменений была приостановлена до завершения процессом DBWn обработки контрольной точки. Для ускорения обработки сервер Oracle отдал все вычислительные мощности процессу DBWn.

При соответствующей настройке сервера это сообщение в журнале появляться не должно. Если оно все же есть, значит, имеют место искусственные, ненужные ожидания, которых можно избежать. Цель (в большей степени администратора базы данных, чем разработчика) - иметь достаточно активных файлов журнала повторного выполнения. Это предотвратит попытки сервера использовать файл журнала, прежде чем будет закончена обработка контрольной точки. Если это сообщение выдается часто, значит, администратор базы данных не выделил для приложения достаточного количества активных журналов повторного выполнения или процесс DBWn не настроен как следует. Разные приложения генерируют различные объемы информации повторного выполнения. Системы класса СППР (системы поддержки принятия решений, выполняющие только запросы), естественно, будут генерировать намного меньше информации повторного выполнения, чем системы ООТ (системы оперативной обработки транзакций). Система, манипулирующая изображениями в больших двоичных объектах базы данных, может генерировать во много раз больше данных повторного выполнения, чем простая система ввода заказов. В системе ввода заказов со 100 пользователями генерируется в десять раз меньше данных повторного выполнения, чем в системе с 1000 пользователей. Правильного размера для журналов повторного выполнения нет, - он просто должен быть достаточным.

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

Резервная база данн1х. Когда заполненные журналы повторного выполнения посылаются на другую машину и там применяются к копии текущей базы данных, необходимо много небольших файлов журнала. Это поможет уменьшить рассин-хронизацию резервной базы данных с основной.

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

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

Архивный журнал повторного выполнения

База данных Oracle может работать в двух режимах - NOARCHIVELOG и ARCHIVELOG. Я считаю, что система, используемая в производственных условиях, обязательно должна работать в режиме ARCHIVELOG. Если база данных не работает в режиме ARCHIVELOG, данные рано или поздно будут потеряны. Работать в режиме NOARCHIVELOG можно только в среде разработки или тестирования.

Эти режимы отличаются тем, что происходит с файлом журнала повторного выполнения до того как сервер Oracle его перепишет. Сохранять ли копию данных повторного выполнения или разрешить серверу Oracle переписать ее, потеряв при этом навсегда? - очень важный вопрос. Если не сохранить этот файл, мы не сможем восстановить данные с резервной копии до текущего момента. Предположим, резервное копирование выполняется раз в неделю, по субботам. В пятницу вечером, после того как за неделю было сгенерировано несколько сотен журналов повторного выполнения, происходит сбой диска. Если база данных не работала в режиме ARCHIVELOG, остается только два варианта дальнейших действий.

Удалить табличное пространство/пространства, связанные со сбойным диском. Любое табличное пространство, имеющее файлы данных на этом диске, должно быть удалено, включая его содержимое. Если затронуто табличное пространство SYSTEM (словарь данных Oracle), этого сделать нельзя.

Восстановить данные за субботу и потерять все изменения за неделю.

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

Часто приходится слышать, что в производственных системах режим ARCHIVELOG не нужен. Это глубочайшее заблуждение. Если не хотите в один момент потерять данные, сервер должен работать в режиме ARCHIVELOG. Мы используем дисковый массив RAID-5 и абсолютно защищены - вот типичное оправдание. Я сталкивался с ситуациями, когда по вине изготовителя все пять дисков массива одновременно останавливались. Я видел поврежденные аппаратным контроллером файлы данных, которые в поврежденном виде надежно защищались дисковым массивом. Если имеется резервная копия данных на момент, предшествующий сбою оборудования, и архивы не повреждены, - восстановление возможно. Поэтому нет разумных оснований для того, чтобы не использовать режим ARCHIVELOG в системе, где данные представляют хоть какую-нибудь ценность. Производительность - не основание. При правильной настройке на архивирование расходуется незначительное количество ресурсов системы. Это, а также тот факт, что быстро работающая система, в которой данные теряются, - бесполезна, заставляет сделать вывод, что, даже если бы архивирование журналов замедляло работу системы в два раза, оно в любом случае должно выполняться.