Размер SGA, ассоциируемой с сегодняшними экземплярами Oracle, может быть экстремально большим, но независимо от того, насколько мала или велика эта область, кому-то нужно заботиться о деятельности, связанной с экземпля­ром. Такими задачами управляет небольшая армия процессов операционной си­стемы (UNIX) или потоков (Windows NT). Важно четко различать фоновые и обычные процессы. Фоновые процессы не зависят от подключений пользовате­ля. Они производят операции над экземпляром и базой данных от имени всех пользователей, при этом выполняя такие операции, как запись в файлы дан­ных, восстановление базы данных или разрешение ошибок. Некоторые из про­цессов помогают в увеличении общей производительности.

На рис. 5.1 показаны все фоновые процессы. Некоторые из них являются

обязательными (без них не может работать Oracle), мы, конечно, назовем их.

Все остальные используются для        специализированных опций или

для повышения производительности. Они будут обсуждаться в соответствую­щих разделах. В приведенной ниже таблице определяются обязательные про­цессы и два дополнительных процесса по умолчанию.

SMON

Системный монитор отвечает за многие рутинные работы сопровождения в SGA .и даже в табличных пространствах, например за объединение свободного пространства. SM0N управляет сегментами отката (уменьшает их в размере, если установлен параметр OPTIMAL) и выполняет операторы восстановления во время запуска (если это необходимо).

PMON

Проверяет процессы переднего плана Oracle (процессы сервера). Это первый стартующий процесс. Он наблюдает за такими задачами, как очистка памяти, пространства процесса, блокировок завершенных подключений и потерянных соединений. Является обязательным.

или

Реализует программу записи базы данных. Это обычно единственный процесс, который действительно пишет блоки данных в файлы в базе данных. Исключением можно считать случаи, когда работает (в прямом режиме) программа SQL*Loader или параметр SORT_DIRECT_WRITES установлен на TRUE. (Конечно, процесс СКРТ во время записи контрольных точек пишет в заголовки, и их может быть больше одного.) Данный процесс включен в управление записью модифицированных блоков из кэша буфера базы данных на диск.

Является обязательным.

LGWR        Процесс записи журнала управляет буфером журнала обновлений. Пишет

информацию об обновлениях из буфера журнала в журнальные файлы на диске.

Является обязательным.

Процесс восстановления, который требуется для разрешения сомнительных распределенных транзакций. Он разрешает проблемы, применяя конструкцию двухфазного фиксирования изменений. Это необходимо, если используются любые распределенные конструкции типа DBUNKS. Стартует автоматически, если параметр DISTRIBUTED .TRANSACTIONS является выводимым либо ему явно присвоено ненулевое значение.

СКРТ        Этот используемый для улучшения производительности процесс помогает при

завершении контрольных точек, уменьшая нагрузку на процесс LGWR. Начиная с Огас1е8 и выше, стал обязательным фоновым процессом.

Несколько дополнительных замечаний о LGWR и DBWR. Эти два процесса являются поистине рабочими лошадками экземпляра Oracle и в этом качестве они часто становятся источниками узких мест. Конечно, поскольку оба являют­ся процессами, связанными с вводом/выводом, необходимо принимать меры, чтобы избежать конкуренции между ними и постараться предотвратить ее. Что­бы увидеть и понять, почему это так, нужно выяснить еще несколько тонкостей, связанных с их работой.

DBWR пишет копии модифицированных блоков таблиц, индексов, сегмен-
тов отката и временных сегментов (если только не установлен на TRUE пара-
метр        в определенные моменты, а именно:

Каждые трисекунды,

В случае, если список грязных блоков достигает своей пороговой длины (внутренняя установка системы).

Если другой процесс ищет список наиболее давно использовавшихся блоков (LRU.least of recently used blocks) и не может найти свободного буфера после того, как достигнуто внутренне устанавливаемое число просматриваемых блоков.

•        При выполнении контрольной точки.

переписывает буферы протокола в текущий журнальный файл также

в некоторые моменты, а именно:

Каждые три секунды (независимо otDBWR).

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

В тех случаях, когда информация протокола равна одной трети размера буфера протокола, записанного в буфер протокола. Например, если буфер протокола имеет размер 131072 байта, то после записи в него 43690 байт новой информации программа записи журнала скопирует новую информацию протокола на диск. Начиная с OracleS, программа записи журнала выполняет запись на диск в том случае, если верно условие MIN(1 Мбайт, LOG BUFFER/3).

При выполнении контрольных точек.

Когда его работа является следствием работы DBWR

(см. нижеследующее замечание).

Обратили внимание, в чем совпадают эти два перечня? Правильно, в обоих перечнях указаны контрольные точки. Итак, теперь можно видеть, что именно здесь в моменты выполнения контрольных точек могут зарождаться очаги кон­куренции. Поэтому конфигурирование файлов данных и журнальных файлов

на одни и те же физические устройства может привести к ожиданиям ввода/вы-
вода при выполнении контрольных точек        только у вашего устройства нет

адекватных возможностей для обработки ввода/вывода). Замечание

Хотя DBWR и "просыпается" каждые три секунды, чтобы произвести запись, LGWR опрашивается каждые три секунды и при каждой записи, производимой DBWR, чтобы иметь уверенность в том, что элементы протокола, ассоциированные с грязными блоками, действительно записаны в журнал. Это должно происходить для предотвращения перехода базы данных в несогласованное состояние в случае сбоя экземпляра. Необходимо записать в журнальные файлы элементы протокола, относящиеся к грязным блокам, до того, как эти грязные блоки сами будут записаны в файлы данных.

Один дополнительный штришок к процессу создания контрольной точки: начиная с OracleS, он через каждые три секунды записывает в управляющие файлы контрольные сообщения типа "я живой" для экземпляра/базы данных. Это делается для того, чтобы помочь определить начальный момент восстанов­ления, когда это необходимо и возможно.