DeepEdit!

Буфер журнала обновлений представляет собой первый шаг записи в базу данных изменений данных. Он обычно является самым маленьким кэшем в SGA, Это буфер фиксированного размера, который определяется параметром инициализации Oracle LOGJBUFFER. Буфер журнала обновлений используется

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

Процесс LGWR читает содержимое буфера журнала обновлений и записыва­ет его в файлы онлайновых журналов обновлений на диске. В зависимости от

того, работает ли база данных в режиме arcivelog или нет, файлы журналов об-
новлений будут или не будут копироваться процессом ARCH в назначенные ад-
реса хранения архивных        Процесс LGWR можно сравнить с работой
мальчика-копировщика из редакции газеты. Для тех из вас, кому довелось жить
в некоторых уголках бывшей Британской        это понятие должно быть
очень хорошо знакомо. В былые дни, когда электронная почта и процессы элек-
тронного документооборота существовали только как продукты        фанта-
зии, именно этот персонаж заворачивал в офисе всем (мальчик-копировщик
вполне мог быть и девочкой).

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

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

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

Мы ставим своей целью объяснить простыми словами, как работает буфер
журнала обновлений и поддерживающие его системы - LGWR и сам журнал об-
новлений. Да, звучит здорово! Когда процесс пользователя издает оператор
DML, связанный с ним процесс сервера должен гарантировать, что произведен-
ные в результате выполнения этого оператора изменения можно будет восста-
новить в случае отказа (сбоя) экземпляра или носителя информации. Для
достижения этого и используются буфер журнала обновлений, некоторые спе-
цифические защелки обновлений (внутренние структуры, которые Oracle при-
меняет для обеспечения взаимоисключающего доступа к своим структурам
памяти), с которыми мы скоро познакомимся поближе,        и журналы об-

новлений. Здесь очень важен порядок событий. Исследуем этот процесс, так как он существенно изменился в Oracle 7.3:

Процесс пользователя издает команду вставки, обновления или удаления. Предположим, что это начало транзакции и Oracle назначает

для этой операции идентификатор транзакции.

2.        Процесс сервера, ассоциированный с процессом пользователя, читает

в память требующиеся данные, индексы и блоки отката и блокирует

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

3.        Далее процесс сервера сначала приобретает защелку копии протокола,
что является обязательным предварительным

(пререквизитом), без выполнения которого процесс не может начать
запись в буфер журнала обновлений. Однако запись пока еще не
началась. Полезно знать, что защелок копии протокола ровно столько,
сколько их было определено параметром инициализации Oracle
LOG_SlMULTANEOUS_COPIES. В        этот параметр стал

устаревшим (он автоматически устанавливается равным удвоенному числу ЦП). Но в более ранних выпусках, например Oracle 7.3.x, этот параметр можно установить равным восьмикратному числу ЦП. Для платформ некоторых ОС в Oracle 7.3.4 была восстановлена именно такая установка данного параметра. Задание максимального значения этого параметра для любой конкретной системы не приводит к заметным накладным расходам.

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

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

сбоя экземпляра или носителя информации.)

Элемент сервера освобождает защелку копии протокола.

Как только информация протокола будет записана в буфер журнала обновлений, процесс сервера запишет информацию для отката в 

блоки 

сегмента отката, назначенные для этой транзакции. Такая информация применяется, если процесс пользователя издаст вместо команды фиксации результатов транзакции (commit) команду отката (rollback). Заметьте, что элементы отката тоже генерируют собственный протокол и также должны быть зарегистрированы в буфере журнала обновлений.

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

Учитывая, что буфер журнала обновлений является круговым, одновременная запись в эту структуру памяти может происходить и будет происходить. Это, конечно, зависит от того, как быстро приобретается и освобождается защелка распределения протокола. Отметьте также, что обработка       ' информации протокола имеет более высокий приоритет по сравнению со всеми видами изменения данных или прочими видами деятельности, т. е. эта обработка выполняется в первую очередь. С точки зрения настройки это означает, что все, что задерживает помещение данной информации в буфер журнала обновлений, будет задерживать и все остальное. Так что пожелаем этому малышу из SGA удачи! Помните историю о мальчике- копировщике!

Каждые три секунды (независимо от        Да, начиная сОгас1е8,

у него имеется собственный таймер.

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

Если в буфер журнала изменений записывается информация протокола, равная по объему одной трети размера этого буфера. Например, когда размер буфера журнала изменений равен 131072 байта, LGWR записывает на диск новую информацию протокола, если объем помещаемой в буфер информации составит 43690 байт. Начиная с Oracle8, LGWR будет производить запись в журналы обновлений, если справедливо выражение MIN(lMB,LOG_BUFFER/3). Это сделано для того, чтобы поддерживать лучшую производительность, когда экземпляры Oracle конфигурированы с большими буферами журнала обновлений. Однако не стоит понимать вышесказанную фразу как рекомендацию устанавливать большие размеры буферов журнала обновлений. Мы пытаемся показать вовсе не то, что буфер журнала обновлений никогда не заполняется больше, чем на одну треть. Мы пытаемся донести до читателей, что, когда он заполнится больше, чем на одну треть, LGWR запишет его содержимое на диск. Однако, учитывая круговую природу буфера, оставшиеся две его трети будут использованы для записей других процессов сервера, которым требуется сделать запись в буфер журнала обновлений. В Огас1е8 и в более поздних версиях эта одна треть не превышает размера в 1 Мбайт (кроме случаев, когда экземпляр конфигурирован с буфером журнала обновлений большим 3 Мбайт) в связи с приведенной выше формулой. Говоря другими словами, при установке размера буфера журнала обновлений равным 15 Мбайт, LGWR все равно инициирует запись,

если потребуется записать в буфер журнала обновлений более 1 Мбайта

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

шестой до двух третей наполнения. Не рассчитывайте на это!

При контрольных точках.

Когда это затребовано процессом DBWR. Но необходимо всегда

помнить, что модифицированные блоки базы данных всегда

записываются после того, как соответствующие элементы протокола для этих блоков записаны на диск.

Размер данного буфера можно увидеть сразу же после старта экземпляра в строке "Redo log buffers" сообщений команды запуска:

Этот размер можно также выяснить, задав запрос к

select Name, Value

from VIPARAMETER

' where Name = 'log.buffer1;

NAME        VALUE

524288

log_buffer

Значение здесь приведено в байтах. Значение по умолчанию этого парамет­ра изменяется от версии к версии. В Oracle 8.0 минимально распределяемое зна­чение буфера журнала обновлений составляет 73728 байт (72 Кбайт). В Oracle 8.1.5 значение по умолчанию составляет 524288 байт (512 Кбайт).

Рекомендуется начинать с небольших значений и постепенно в случае необ­ходимости увеличивать размер буфера до тех пор, пока этот ресурс не переста­нет быть точкой конкуренции. Мы знаем многих АБД, которые для своих сред начинали со значения LOGJBUFFER = 131072 (128 Кбайт). И это очень хорошее значение для начала. 

Увеличивайте размер буфера только в том случае, если имеются связанные с ним события ожидания 

(см. ниже, раздел "События ожидания, влияю­щие на буфер журнала обновлений"). Если выбрать размер буфера, равный 32 Мбайт, то можно сказать, что он скорее всего завышен и вы зря расходуете

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