Данные формируются в SGA в буфере журнала повторного выполнения. Как только транзакция фиксируется, фоновым процессом LGWR («писатель» журнальных файлов – пишет на диск информацию об измененных данных, поддерживает целостность данных) данные сбрасываются на диск (также данные из буфера журнала повторного выполнения сбрасываются на диск при простое LGWR более трех секунд, или при заполнении буфера журнала повторного выполнения на треть, или при записи в него 1 Мбайта данных).

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

Процесс LGWR в журналы записывает последовательно, а не вразброс, как вынужден выполнять ввод-вывод процесс DBWn. Это является главной причиной разделения функции записи на диск на два процесса: процесс LGWR и процесс DBWn.

Упрощенно все это можно описать таким образом:

При чтении данных блоки запоминаются в буферный кеш. При изменении данных в блоке данных изменения выполняются в блоках буферного кеша.

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

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

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

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

Поэтому свою работу должен выполнить фоновый процесс DBWn, который отвечает

• за освобождение буферного кеша при заполнении
• обработку контрольных точек

Контрольная точка

Алгоритм, описанный ниже, работал до версии 8.1. В более высоких версиях появились понятия «инкрементальная» и «нормальная» контрольные точки. Этот механизм я пробую описать в другой статье –ищите на моём блоге. Принцип работы контрольной точки остался тем же – запись грязных блоков на диск. В основном изменился принцип вызова контрольной точки, какие и в каком порядке грязные блоки пишутся на диск.

Обработка контрольной точки состоит в сбросе грязных (измененных) блоков из буферного кеша на диск. Обработка контрольной точки может быть вызвана многими событиями:

• достигнут предел LOG_CHECKPOINT_TIMEOUT
• величина в байтах LOG_CHECKPOINT_INTERVAL* size of IO OS blocks уже записана в текущий журнал,
• ALTER SYSTEM SWITCH LOGFILE,
• ALTER SYSTEM CHECKPOINT

Но чаще всего выполнение контрольной точки вызывается переключением журнала повторного выполнения: фоновый процесс DBWn сбрасывает на диск все грязные блоки, защищенные файлом журнала, с которого произошло переключение. Пока процесс DBWn не сбросит все блоки, защищаемые этим журнальным файлом, сервер Oracle не сможет его повторно использовать. Этот журнал будет иметь статус ACTIVE. Если попытаться использовать его раньше, чем процесс DBWn завершит обработку контрольной точки, в журнал сообщений (alert log) будет выдано следующее сообщение:

...
Thread 1 cannot allocate new log, sequence 66
Checkpoint not complete
  Current log# 2 seq# 65 mem# 0: C:\ORACLE\ORADATA\MY_DB\REDO02.LOG
...

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

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

Исходя из своего весьма скромного опыта, могу посоветовать следующее:

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

В конечном счете, выбирать и нести ответственность за свой выбор Вам.

Заключение

В любой момент времени оракл переносит записи из журнального буфера только в один оперативный журнальный файл, который называется текущим CURRENT. Журнальный файл, который ещё необходим для восстановления экземпляра (не все измененные блоки из буферного кеша сброшены на диск), называется активным ACTIVE. Ну и те журнальные файлы, которые уже не нужны для восстановления экземпляра, называются неактивными INACTIVE. Если база данных работает в режиме ARCHIVELOG, то оперативный журнальный файл не будут использован повторно до тех пор, пока не будет на его основе процессом ARCn сформирован архивный журнальный файл.

Рекомендую для общего развития почитать статьи по контрольной точке на моём блоге