Oracle для профессионалов
Оперативный журнал повторного выполнения
В каждой базе данных Oracle есть как минимум два оперативных файла журнала повторного выполнения. Эти оперативные файлы журнала повторного выполнения имеют фиксированный размер и используются циклически. Сервер Oracle выполняет запись в файл журнала 1, а когда доходит до конца этого файла, — переключается на файл журнала 2 и переписывает его содержимое от начала до конца. Когда заполнен файл журнала 2, сервер переключается снова на файл журнала 1 (если имеется всего два файла журнала повторного выполнения; если их три, сервер, разумеется, переключится на третий файл).
Переход с одного файла журнала на другой называется переключением журнала. Важно отметить, что переключение журнала может вызвать временное "зависание" плохо настроенной базы данных. Поскольку журналы повторного выполнения используются для восстановления транзакций в случае сбоя, перед повторным использованием файла журнала необходимо убедиться, что его содержимое не понадобится в случае сбоя. Если сервер Oracle "не уверен", что содержимое файла журнала не понадобится, он приостанавливает на время изменения в базе данных и убеждается, что данные, "защищаемые" этой информацией повторного выполнения, записаны на диск. После этого обработка возобновляется, и файл журнала переписывается. Мы затронули ключевое понятие баз данных — обработку контрольной точки. Чтобы понять, как используются оперативные журналы повторного выполнения, надо разобраться с обработкой контрольной точки, использованием буферного кеша базы данных и рассмотреть функции процесса записи блоков базы данных (Database Block Writer - DBWn). Буферный кеш и процесс DBWn подробно рассматриваются ниже, но мы все равно забегаем вперед, так что имеет смысл поговорить о них.
В буферном кеше базы данных временно хранятся блоки базы данных. Это структура в области SGA разделяемой памяти экземпляра Oracle. При чтении блоки запоминаются в этом кеше (предполагается, что в дальнейшем их не придется читать с диска). Буферный кеш — первое и основное средство настройки производительности сервера. Он существует исключительно для ускорения очень медленного процесса ввода-вывода. При изменении блока путем обновления одной из его строк изменения выполняются в памяти, в блоках буферного кеша. Информация, достаточная для повторного выполнения этого изменения, записывается в буфер журнала повторного выполнения — еще одну структуру данных в области SGA. При фиксации изменений с помощью оператора COMMIT сервер Oracle не записывает на диск все измененные блоки в области SGA. Он только записывает в оперативные журналы повторного выполнения содержимое буфера журнала повторного выполнения. Пока измененный блок находится в кеше, а не на диске, содержимое соответствующего оперативного журнала может быть использовано в случае сбоя экземпляра. Если сразу после фиксации изменения отключится питание, содержимое буферного кеша пропадет.
Если это произойдет, единственная запись о выполненном изменении останется в файле журнала повторного выполнения. После перезапуска экземпляра сервер Oracle будет по сути повторно выполнять транзакцию, изменяя блок точно так же, как мы это делали ранее, и фиксируя это изменение автоматически. Итак, если измененный блок находится в кеше и не записан на диск, мы не можем повторно записывать соответствующий файл журнала повторного выполнения.
Тут и вступает в игру процесс DBWn. Это фоновый процесс сервера Oracle, отвечающий за освобождение буферного кеша при заполнении и обработку контрольных точек. Обработка контрольной точки состоит в сбросе грязных (измененных) блоков из буферного кеша на диск. Сервер Oracle делает это автоматически, в фоновом режиме. Обработка контрольной точки может быть вызвана многими событиями, но чаще всего — переключением журнала повторного выполнения. При заполнении файла журнала 1, перед переходом на файл журнала 2, сервер Oracle инициирует обработку контрольной точки. В этот момент процесс DBWn начинает сбрасывать на диск все грязные блоки, защищенные файлом журнала 1. Пока процесс 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 не настроен как следует. Разные приложения генерируют различные объемы информации повторного выполнения. Системы класса DSS (системы поддержки принятия решений, выполняющие только запросы), естественно, будут генерировать намного меньше информации повторного выполнения, чем системы OLTP (системы оперативной обработки транзакций). Система, манипулирующая изображениями в больших двоичных объектах базы данных, может генерировать во много раз больше информации повторного выполнения, чем простая система ввода заказов. В системе ввода заказов со 100 пользователями генерируется в десять раз меньше информации повторного выполнения, чем в системе с 1000 пользователей. "Правильного" размера для журналов повторного выполнения нет, — он просто должен быть достаточным.
При определении размера и количества оперативных журналов повторного выполнения необходимо учитывать много факторов. Они, в общем, выходят за рамки книги, но я перечислю хотя бы отдельные, чтобы вы поняли, о чем речь.
