Шаг 79 - Архитектура БД Oracle ЧАСТЬ VI

Продолжаем разбирать фоновые процессы. Следующий на очереди, процесс DBWR.

DBWR - это (DataBase Writer) один из, пожалуй, ключевых процессов отвечающих за перенос данных. Он отвечает за перенос обновленных блоков и производит перезапись в следующих случаях:

  1. Обнаружена контрольная точка.
  2. Количество элементов в dirty - списке достигло заданной величины - половина значения параметра DB_BLOCK_WRITE_BATCH из файла init.ora.
  3. Количество использованных буферов достигло величины, заданной параметром DB_BLOCK_MAX_SCAN из файла init.ora.
  4. Истек заданный для процесса DBWR интервал времени (3 с).

Итак, блоки, попавшие в dirty - список, переносятся в файлы данных. Вместо того, чтобы записывать каждый блок на диск сразу же после внесения изменений процесс DBWR ждет, пока не будет выполнено одно из вышеуказанных условий, затем просматривает dirty - список и все отмеченные в нем блоки переписываются в файлы данных на диске. Такой метод организации групповой перезаписи модифицированных блоков БД позволяет уменьшить влияние скоростных характеристик жестких дисков на производительность системы в целом. Процесс DBWR имеет множество методов настройки, в зависимости от характеристик и размеров БД. Например, если один процесс не успевает за обновлением данных, то их можно запустить несколько для этого поменяйте параметр DB_WRITERS в файле init.ora с 1, на цифру количества дисков системы БД. Так же можно изменить параметр DB_BLOCK_CHECKPOIT_BATCH. Он определяет максимальное количество блоков, которые процесс DBWR записывает для каждой контрольной точки (что, это такое мы еще разберем). Самое главное при настройке DBWR не терять чувство реальности! :) Так как некоторые параметры могут наоборот снизить производительность системы.

Далее, процесс LGWR - (Log Writer). Это четвертый и последний процесс из числа тех, которые обязательны для нормального функционирования БД Oracle. Так, что же он делает? Процесс LGWR, производит перезапись информации из буфера журнала транзакций, которая находится в ГСО (SGA), в файлы оперативного журнала. А, теперь посмотрим при каких условиях это происходит:

  1. Транзакция принимается. (Истекает время ожидания для процесса LGWR)
  2. Буфер журнала транзакций заполняется на треть.
  3. Процесс DBWR(!) завершает перезапись данных из кэш буфера после обнаружения контрольной точки.

Так же LGWR обрабатывает завершение транзакций для нескольких пользователей одновременно, когда один или несколько пользователей запрашивают завершение в то время, когда LGWR еще не произвел перезапись буфера. Так же очень важный момент состоит в том, что Oracle не считает транзакцию выполненной до тех пор, пока процесс LGWR не перезапишет данные о ней из буфера журнала транзакций в файл. И само сообщение о завершении транзакции передается процессу сервера не после изменения данных в файле данных, а после успешного завершения записи в файл журнала транзакций. В файле init.ora, имеется два параметра, которые влияют на работу процесса LGWR. Это параметры LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT. Давайте остановимся на них чуть подробнее. Одной из побочных для процесса LGWR задач, является обработка контрольных точек. LGWR - работает с ними только при условии, что процесс CKPT активирован, а работать с контрольными точками это его прямая обязанность. Так вот эти два параметра непосредственно и определяют, интервалы следования контрольных точек в самой БД. При активации параметра LOG_CHECKPOINT_INTERVAL, контрольная точка генерируется при условии, что указанное количество блоков операционной системы (а, не блоков БД!) записывается в журнал транзакций. А вот при активации параметра LOG_CHECKPOINT_TIMEOUT контрольная точка генерируется при условии, что истек период ожидания времени в секундах. Теперь ясно видно, что обработка контрольных точек при функционировании БД довольно не простая задача. Эти параметры нужно использовать весьма осторожно! Если для настройки используется параметр LOG_CHECKPOINT_INTERVAL, то указанное количество блоков ОС должно соотносится с размером группы журнала транзакций! Когда эта группа заполняется - генерируются контрольная точка. Так же можно использовать параметр LOG_CHECKPOINT_TO_ALERT из файла init.ora, если он активирован то, после генерации каждой контрольной точки будет проставлена соответствующая пометка, в файле регистрации alert.log, что может оказаться полезным при давнейшем процессе анализа генерации контрольных точек БД. Надеюсь, если кому-либо понятно хотя бы половина моего изложения, я буду весьма рад! :)


Предыдущий Шаг | Следующий Шаг | Оглавление
Автор Летучий Сергей - 9.12.2003