Известно, что LGWR записывает содержимое буфера журнала обновлений в
файлы журнала обновлений на диске. В этих файлах находятся постоянные записи обо всех произведенных в базе данных изменениях. Запись протокола содержит как старое, так и новое значения данных. У каждой базы данных должны
быть по крайней мере два файла журнала обновлений (но, конечно, их может
быть и        Oracle использует эти файлы для восстановления после сбоя экземпляра или носителя данных. По этой причине следует защищать журналы от любого разрушения диска или проблем с вводом/выводом. Неплохо было бы иметь несколько копий файлов журналов обновлений на различных внешних устройствах. Обратитесь к руководству администратора Oracle, чтобы получить дополнительную информацию о том, как конфигурировать несколько журналов обновлений и групп журналов обновлений. Ниже будет рассказано об их физиче­ских размерах и о том, как они влияют на производительность базы данных.

Как задать размер файлов журнала обновлений

При ответе на вопрос: "Как влияет размер файла журнала обновлений на производительность базы данных?" в одном мы уверены абсолютно, он должен быть по размеру не меньше, чем LOGBUFFR, иначе не миновать проблем. Фай­лы журнала обновлений являются обычными файлами ОС и записываются при­нятыми в ОС блоками.

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

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

С другой стороны, малые по размеру файлы журнала обновлений вызывают большее количество контрольных точек и дополнительные заминки роста про­изводительности вследствие связанной с ними деятельности, и при этом посто­янно загружен процесс ARCH. Но зато восстановление экземпляра происходит практически моментально! Поэтому пусть каждый сделает свой выбор сам. К этомуже обсуждению относится и новый параметр Oracle8i, получивший назва­ние FAST_START_IO_TARGET. Он обеспечивает управление максимальным ко­личеством операций ввода/вывода, которое нельзя превысить во время восстановления экземпляра. Если этот параметр установлен, DBWR перепишет грязные блоки на диск более агрессивным образом.

Итак, дилемма - что из перечисленного является более        Иногда сле-

дует идти на компромисс между производительностью и доступностью. А ведь
есть и другие важные вещи. Только размер ничего не решает! Может быть, при-
дется экспериментально определить, при каком размере настраиваемая среда
будет        лучше всего.

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

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

возникнет сообщение об ошибке 

checkpoint cannot complete. 

Поэтому, чем меньше
число журналов обновлений, тем вероятнее появление такой ошибки. Напри-
мер, если сконфигурировано две группы журналов обновлений, в момент пере-
ключения журналов должно быть доступным 50% общего размера памяти
журналов обновлений. При четырех группах журналов обновлений доступным
должно быть всего 25% общего размера памяти журналов обновлений. Эмпири-
ческие свидетельства (благодаря некоторым экспериментам, проведенным
Крейгом        из OraPub Inc.) предполагают, что закон уменьшения

отдачи подталкивает примерно к десяти группам журналов обновлений.

Поэтому для систем с интенсивной записью в журнал можно говорить о кон­фигурировании большего количества групп онлайнового журнала обновлений,

чем минимально допустимые две группы.