Продолжаем разбирать фоновые процессы. Следующий на очереди, процесс DBWR.
DBWR - это (DataBase Writer) один из, пожалуй, ключевых процессов отвечающих за перенос данных. Он отвечает за перенос обновленных блоков и производит перезапись в следующих случаях:
Итак, блоки, попавшие в dirty - список, переносятся в файлы данных. Вместо того, чтобы записывать каждый блок на диск сразу же после внесения изменений процесс DBWR ждет, пока не будет выполнено одно из вышеуказанных условий, затем просматривает dirty - список и все отмеченные в нем блоки переписываются в файлы данных на диске. Такой метод организации групповой перезаписи модифицированных блоков БД позволяет уменьшить влияние скоростных характеристик жестких дисков на производительность системы в целом. Процесс DBWR имеет множество методов настройки, в зависимости от характеристик и размеров БД. Например, если один процесс не успевает за обновлением данных, то их можно запустить несколько для этого поменяйте параметр DB_WRITERS в файле init.ora с 1, на цифру количества дисков системы БД. Так же можно изменить параметр DB_BLOCK_CHECKPOIT_BATCH. Он определяет максимальное количество блоков, которые процесс DBWR записывает для каждой контрольной точки (что, это такое мы еще разберем). Самое главное при настройке DBWR не терять чувство реальности! :) Так как некоторые параметры могут наоборот снизить производительность системы.
Далее, процесс LGWR - (Log Writer). Это четвертый и последний процесс из числа тех, которые обязательны для нормального функционирования БД Oracle. Так, что же он делает? Процесс LGWR, производит перезапись информации из буфера журнала транзакций, которая находится в ГСО (SGA), в файлы оперативного журнала. А, теперь посмотрим при каких условиях это происходит:
Так же 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, что может оказаться полезным при давнейшем процессе анализа генерации контрольных точек БД. Надеюсь, если кому-либо понятно хотя бы половина моего изложения, я буду весьма рад! :)