Теоретическая часть продолжается. :) Разберем одну из концептуальных частей сервера Oracle, следующий пункт: Буфер журнала транзакций (Redo Log Buffer).
Он представляет собой циклический буфер. Как только буфер заполнится и поступает новая информация, то происходит перезапись в файлы журналов транзакций. Данные о транзакциях хранятся до тех пор, пока не будут переписаны в файл оперативного журнала транзакций. Размер буфера журнала транзакций задается, параметром LOG_BUFFER, файла init.ora. Значение параметра указывает размер буфера в байтах. Если это значение невелико то фоновый процесс LGWR будет часто переписывать информацию из буфера в файл и тем самым, несколько замедлять работу системы. В принципе тоже будет происходить и при большой интенсивности обращений к БД. Давайте дадим вот такой запрос:
SELECT a.VALUE FROM V$SYSSTAT a WHERE NAME = 'redo log space request' /
Получаем:
SQL> SELECT a.VALUE FROM V$SYSSTAT a
2 WHERE NAME = 'redo log space request'
3 /
VALUE
----------
0
С помощью системного представления V$SYSSTAT можно оперативно контролировать процесс записи в журнал. Данный запрос показывает как долго пользовательские процессы, находились в состоянии ожидания при обращении к буферу журнала транзакций. В моем случае значение 0, говорит лишь о том, что моя домашняя БД, пока ничем особым не занималась, но может ей еще повезет! :) Для того, чтобы гарантировать последовательный характер записи в буфер журнала сервер Oracle управляет доступом к нему при помощи "защелок" (latch). Такая защелка представляет собой блокировку процессом Oracle некоторой структуры в памяти - аналогично, блокировке файла или строки таблицы. Процесс блокирует посторонние обращения к памяти, выделенной для буфера журнала транзакций. Таким образом, если один процесс наложил защелку на буфер, к нему нельзя обратиться, пока ее не снимут. Oracle ограничивает количество транзакций, данные о которых заносятся в журнал одновременно параметром LOG_SMALL_ENTRY_MAX_SIZE. Значение параметра в байтах. Значение, принимаемое системой по умолчанию может меняться в зависимости от используемой OS. Используя защелки копий журнала транзакций, несколько процессов могут одновременно записывать информацию в буфер журнала транзакций. Так же, можно добавить, что мониторинг работы с буфером журнала транзакций осуществляется с помощью динамического представления V$LATCH.
Теперь настало время поговорить, о так называемых, фоновых промессах Oracle. В процессе работы сервер, одновременно работает с тысячами или даже более записями в таблицах, БД. Проводит выборки данных, по запросам пользователей, изменяет и удаляет данные. Для того, чтобы весь этот комплекс работал стабильно и без сбоев, вся работа делиться между несколькими вспомогательными программами, которые действуют независимо одна от другой. В совокупности эти программы называются фоновыми процессами сервера Oracle. Сразу заметим, что для платформы Windows NT фоновые процессы реализованы как потоки к сервисам Oracle. Это позволяет более эффективно использовать адресное пространство памяти общего пользования. Итак к фоновым процессам относятся следующие:
Так же есть процессы User и Server выполняющие обработку транзакций, конечного пользователя БД. Рассмотрим их, более подробно.
Процессы SMON, PMON это процессы мониторов БД. PMON - (Process Monitor) это процесс, который осуществляет контроль за состоянием подключений к БД. Если по какой-либо причине пользователь потерял контакт с БД, не завершив работы корректно PMON выполнит автоматическую "уборку" (нечто вроде сборщика мусора в языках программирования). Эта "уборка" предусматривает удаление сеанса, закрепленного за прекратившимся процессом, блокировок, которые были им установлены и непринятых транзакций. Так же он освободит ресурсы SGA. Так же PMON следит за процессами сервера и диспетчера и автоматически перезапускает их в случае останова. SMON - чуть более скромен, но так же немаловажен. После запуска БД, он как это не грандиозно звучит, выполняет автоматическое восстановление экземпляра. В случае если у вас отключили свет и сервер успел "слопать" УПС! У меня такие случаи были и пока я выходил сухим из воды! (постучать по дереву). :) Кроме того, он следит за сегментами БД, фиксирует освобождение пространства во временных сегментах и автоматически объединяет их. Так же заметим, что объединение блоков в табличных пространствах, производится при условии, если параметр pctincrease равен 0. Этот параметр, используется при создании табличных пространств. Процессы SMON, PMON должны быть запущены при старте БД, иначе она не будет функционировать. Вот так работают SMON и PMON.