SHPORA.net :: PDA

[ Back ]

Системная Глобальная Область (SGA)

SGA - это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске экземпляра Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Информация в SGA состоит из следующих компонентов (каждый из которых создается в памяти при запуске экземпляра):

- кэш буферов БД - здесь хранятся последние открытые блоки данных. Эти блоки могут содержать данные, которые изменились, но еще не были записаны на диск (грязные блоки); данные, которые не изменялись либо были записаны на диск после изменения (чистые блоки). Так как кэш буферов БД хранит блоки данных на основе алгоритма последних используемых блоков, то наиболее активно используемые блоки постоянно остаются в памяти (тем самым, снижая дисковый ввод/вывод и увеличивая производительность системы).

- буфер журнала изменений - хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно, насколько это возможно. Помните, что журнал изменений используется для восстановления экземпляра СУБД Oracle в случае

сбоя системы.

- разделяемый пул - Это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Разделяемый пул важен, потому что недостаточный объем памяти, выделенный для него, может привести к деградации производительности всей системы. Разделяемый пул состоит из библиотечного кэша и кэша словаря данных.

Библиотечный кэш используется для хранения разделяемых SQL. Здесь для каждого уникального SQL-выражения строиться дерево разбора строк и план исполнения, которые кэшируются (т.е. сохраняются в библиотечном кэше). Если несколько приложений отправляют одинаковые SQL-выражения, то для ускорения работы используется разделяемая SQL-область (так как используются уже разобранные строки и готовый план исполнения, то происходит экономия времени).

Кэш словаря данных содержит набор таблиц и представлений, используемых в качестве ссылок к БД Oracle. Здесь храниться информация о логической и физической структуре БД. Словарь данных содержит следующую информацию:

- пользовательская информация (например, пользовательские привилегии) - ограничения целостности, определенные для таблиц БД - имена и типы данных всех столбцов таблиц БД.

- информация об объеме памяти, определенном и используемом объектами схемы данных.

Oracle часто обращается к словарю данных при разборе SQL-выражений. Эти обращения составляют сущность работы Oracle. Узкие места в словаре данных влияют работу всех пользователей системы Oracle. Поэтому Вы всегда должны быть уверены, что объем памяти, определенный для словаря данных, достаточно велик для кэширования данных. Если кэш словаря данных мал, то Вы заметите значительное снижение производительности. Когда под кэш словаря данных Вы определите достаточный объем памяти, существенных проблем с производительностью быть не должно.

Глобальная область системы (обычно называемая SGA) содержит данные и

управляющую информацию для одного экземпляра ORACLE. Вы могли слышать также

название Shared Global Area (разделяемая глобальная область), эти термины

эквивалентны.

SGA распределяется при запуске экземпляра ORACLE и удаляется при остановке. Текущим пользователям базы необходимо видеть текущие копии информации из SGA.

Исходя из того, что SGA содержит столь часто используемую информацию, лучше (быстрее) держать SGA в основной памяти, нежели чем постоянно считывать с диска. К примеру, SGA содержит:

* информацию, передаваемую между процессами (например - информацию фиксации)

* буферы базы данных

* информацию словаря данных (хранимую в кеше словаря).

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

Размер SGA определяется при старте экземпляра ORACLE и затем не меняется. Для того, чтобы посмотреть размер SGA после старта экземпляра, используйте команду SHOW SGA утилиты SQL*DBA.

Первичное определение размера SGA задается при варьировании параметров файла INIT.ORA.

SGA как разделяемая, так и "записываемая", но в нее может писать информацию только RDBMS. На каждый экземпляр ORACLE распределяется одна SGA.

Программная Глобальная Область (PGA)

Программная Глобальная Область - это такая область памяти, в которой хранятся данные и управляющая информация о серверных процессах Oracle. Размер и содержание PGA определяется опциями, которые Вы указываете при инсталляции Oracle. Эта область состоит из следующих компонентов:

- пространство стека - это память, хранящая переменные сеансов, массивы сеансов и т.д.

- информация сеанса - если Oracle работает не в мультинитевом режиме, то информация сеанса хранится в PGA. В противном случае, информация сеанса хранится в SGA.

- приватная SQL-область - это часть PGA, где хранятся связанные переменные и буферы реального времени.

Глобальная программная область (обычно называемая PGA) содержит данные и управляющую информацию для единственного процесса, например -пользовательского. Можно услышать и эквивалентный термин - Глобальная область процесса (PGA). Это обычно распределяется в момент присоединения пользователя к ORACLE, хотя это зависит от операционных систем. PGA содержит информацию о подключении (как взаимодействовать с программой пользователя) и что процесс делает в ORACLE в текущий момент. Размер PGA может меняться, но не динамически. Он зависит от операционной системы. PGA распределяется в момент подключения пользователя; если требуемая память не доступна, Вы получите сообщение об ошибке. Эта ошибка будет ошибкой ORACLE из диапазона ошибок операционной системы. Достаточно или нет памяти для регистрации, пользователь не может работать вне области PGA.

Следующие параметры файла INIT.ORA влияют на размер PGA для пользовательских процессов:

* OPEN_CURSORS

* OPEN_LINKS

* SAVEPOINTS

* DB_FILES

* LOG_FILES

Размер области PGA для фоновых процессов (DBWR, LGWR, SMON, PMON и ARCH) зависят от некоторых дополнительных параметров.

PGA - это не разделяемая область с возможностью записи. Одна PGA распределяется для каждого процесса пользователя. PGA может читаться и записываться программами ORACLE для единственного пользовательского процесса.

Каждый SQL - оператор, выданный пользовательским процессом, нуждается в области контекста. Область контекста - это отдельная от PGA область памяти, содержащая состояние одного оператора SQL. Область контекста содержит все структуры данных, необходимые для выполнения оператора SQL, включая:

* текст SQL - оператора

* SQL - оператор в оттранслированном виде

* одну строку результата работы оператора и некоторые промежуточные значени

* используемую для выполнения оператора информацию состоянии курсора

* управляющую информацию для сортировки

Экземпляр Oracle состоит из двух частей: области SGA и набора фоновых процессов. Фоновые процессы выполняют рутинные задачи сопровождения, обеспечивающие работу СУБД. Есть, например, процесс, автоматически поддерживающий буферный кеш и при необходимости записывающий блоки данных на диск. Есть процесс, копирующий заполненный файл оперативного журнала повторного выполнения в архив. Еще один процесс отвечает за очистку всех структур, которые использовались завершившимися процессами, и т.д. Каждый из этих процессов решает конкретную задачу, но работает в координации с остальными. Например, когда процесс, записывающий файлы журнала, заполняет один журнал и переходит на следующий, он уведомляет процесс, отвечающий за архивирование заполненного журнала, что для него есть работа.

Есть два класса фоновых процессов: предназначенные исключительно для решения конкретных задач (как только что описанные) и решающие множество различных задач. Например, есть фоновый процесс, обеспечивающий работу внутренних очередей заданий в Oracle. Этот процесс контролирует очередь заданий и выполняет находящиеся в ней задания. Во многом он похож на выделенный сервер, но без подключения к клиенту.

PMON — монитор процессов. Этот процесс отвечает за очистку после нештатного прекращения подключений. Например, если выделенный сервер "падает" или, получив сигнал, прекращает работу, именно процесс PMON освобождает ресурсы. Процесс PMON откатит незафиксированные изменения, снимет блокировки и освободит ресурсы в области SGA, выделенные прекратившему работу процессу. Помимо очистки после прерванных подключений, процесс PMON контролирует другие фоновые процессы сервера Oracle и перезапускает их при необходимости (если это возможно). Если разделяемый сервер или диспетчер сбоит (прекращает работу), процесс PMON запускает новый процесс (после очистки структур сбойного процесса). Процесс PMON следит за всеми процессами Oracle и либо перезапускает их, либо прекращает работу экземпляра, в зависимости от ситуации. Например, в случае сбоя процесса записи журнала повторного выполнения (LGWR) экземпляр надо перезапускать. Это серьезная ошибка и самое безопасное — немедленно прекратить работу экземпляра, предоставив исправление данных штатному процессу восстановления. Это происходит очень редко, и о случившемся надо немедленно сообщить службе поддержки Oracle. Еще одна функция процесса PMON в экземпляре (версия Oracle 8i) — регистрировать экземпляр в процессе прослушивания протокола Net8. При запуске экземпляра процесс PMON опрашивает известный порт (если явно не указан другой), чтобы убедиться, запущен и работает ли процесс прослушивания. Известный/стандартный порт, используемый сервером Oracle, — порт 1521. А что произойдет, если процесс прослушивания запущен на другом порту? В этом случае используется тот же механизм, но адрес процесса прослушивания необходимо указать явно с помощью параметра инициализации LOCAL_LISTENER. Если процесс прослушивания запущен, процесс PMON связывается с ним и передает соответствующие параметры, например имя службы.

SMON — монитор системы. SMON — это процесс, занимающийся всем тем, от чего "отказываются" остальные процессы. Это своего рода "сборщик мусора" для базы данных. Вот некоторые из решаемых им задач.

Очистка временного пространства. С появлением по-настоящему временных табличных пространств эта задача упростилась, но она не снята с повестки дня полностью. Например, при построении индекса выделяемые ему в ходе создания экстенты помечаются как временные (TEMPORARY). Если выполнение оператора CREATE INDEX прекращено досрочно по какой-либо причине, процесс SMON должен эти экстенты освободить. Есть и другие операции, создающие временные экстенты, за очистку которых также отвечает процесс SMON.

Восстановление после сбоев. Процесс SMON после сбоя восстанавливает экземпляр при перезапуске.

Дефрагментация свободного пространства. При использовании табличных пространств, управляемых по словарю, процесс SMON заменяет расположенные подряд свободные экстенты одним "большим" свободным экстентом. Это происходит только в табличном пространстве, управляемом по словарю и имеющем стандартную конструкцию хранения с ненулевым значением параметра PCTINCREASE.

Восстановление транзакций, затрагивающих недоступные файлы. Эта задача аналогична той, которая возникает при запуске базы данных. Процесс SMON восстанавливает сбойные транзакции, пропущенные при восстановлении экземпляра после сбоя по причине недоступности файлов для восстановления. Например, файл мог быть на недоступном или на не смонтированном диске. Когда файл будет доступен, процесс SMON восстановит его.

Восстановление сбойного экземпляра в OPS. В конфигурации Oracle Parallel Server, если одна из машин кластера останавливается (на ней происходит сбой), другая машина в экземпляре откроет файлы журнала повторного выполнения этой сбойной машины и восстановит все данные этой машины.

Очистка таблицы OBJ$. OBJ$ — низкоуровневая таблица словаря данных, содержащая записи практически для каждого объекта (таблицы, индекса, триггера, представления и т.д.) базы данных. Часто там встречаются записи, представляющие удаленные или "отсутствующие" объекты, используемые механизмом поддержки зависимостей Oracle. Процесс SMON удаляет эти ненужные строки.

Сжатие сегментов отката. Процесс SMON автоматически сжимает сегмент отката до заданного размера.

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

Этот список дает представление о том, что делает процесс SMON. Как видно из представленной выше информации о процессах, полученной с помощью команды ps, процесс SMON может со временем потребовать существенных вычислительных ресурсов (команда ps выполнялась на машине, где экземпляр проработал около месяца). Процесс SMON периодически "пробуждается" (или его "будят" другие фоновые процессы) для выполнения задач сопровождения.

RECO — восстановление распределенной базы данных. Процесс RECO имеет очень конкретную задачу: он восстанавливает транзакции, оставшиеся в готовом состоянии из-за сбоя или потери связи в ходе двухэтапной фиксации (2PC). 2PC — это распределенный протокол, позволяющий неделимо фиксировать изменения в нескольких удаленных базах данных. Он пытается максимально снизить вероятность распределенного сбоя перед фиксацией. При использовании протокола 2PC между N базами данных одна из баз данных обычно (но не всегда) та, к которой первоначально подключился клиент, становится координатором. Соответствующий сервер опрашивает остальные N -1 серверов, готовы ли они фиксировать транзакцию. Фактически, этот сервер связывается с остальными N - 1 серверами и просит их подготовиться к фиксации. Каждый из N -1 серверов сообщает о своем состоянии готовности как да (YES) или нет (NO). Если любой из серверов вернул NO, вся транзакция откатывается. Если все серверы вернули YES, координатор рассылает всем N - 1 серверам сообщение о постоянной фиксации.

Если серверы ответили YES и подготовились к фиксации, но до получения директивы о фактической фиксации от координатора происходит сбой сети или возникает какая-то другая ошибка, транзакция становится сомнительной (in-doubt) распределенной транзакцией. Протокол 2PC старается сократить до минимума время, в течение которого это может произойти, но не может полностью предотвратить сомнительные транзакции. Если сбой произойдет в определенном месте и в определенное время, дальнейшую обработку сомнительной транзакции выполняет процесс RECO. Он пытается связаться с координатором транзакции, чтобы узнать ее исход. До этого транзакция остается незафиксированной. Связавшись с координатором транзакции, процесс RECO восстановит либо откатит ее.

Если связаться с координатором долго не удается и имеется ряд сомнительных транзакций, их можно зафиксировать или откатить вручную. Это приходится делать, поскольку сомнительная распределенная транзакция может вызвать блокирование читающих пишущими (единственный случай в СУБД Oracle). Ваш администратор базы данных должен связаться с администратором другой базы данных и попросить его определить состояние сомнительных транзакций. Затем администратор базы данных может зафиксировать или откатить их, предоставив все остальное процессу RECO.

CKPT — обработка контрольной точки. Процесс обработки контрольной точки вовсе не обрабатывает ее, как можно предположить по названию, — это делает процесс DBWn. Процесс CKPT просто содействует обработке контрольной точки, обновляя заголовки файлов данных. Раньше процесс CKPT был необязательным, но, начиная с версии 8.0, он запускается всегда, так что он представлен в результатах выполнения команды ps в ОС UNIX. Ранее заголовки файлов данных обновлялись в соответствии с информацией о контрольной точке процессом записи журнала LGWR (Log Writer). Однако с ростом размеров баз данных и увеличением количества файлов это стало невыполнимой задачей для процесса LGWR. Если процессу LGWR надо обновлять десятки, сотни, а то и тысячи файлов, увеличивается вероятность того, что ожидающие фиксации транзакций сеансы будут ждать слишком долго. Процесс CKPT снимает эту задачу с процесса LGWR.

DBWn — запись блоков базы данных. Процесс записи блоков базы данных (Database Block Writer — DBWn) — фоновый процесс, отвечающий за запись измененных блоков на диск. Процесс DBWn записывает измененные блоки из буферного кеша, чтобы освободить пространство в кеше (чтобы освободить буферы для чтения других данных) или в ходе обработки контрольной точки (чтобы перенести вперед позицию в оперативном файле журнала повторного выполнения, с которой сервер Oracle начнет чтение при восстановлении экземпляра после сбоя). Как было описано ранее, при переключении журнальных файлов сервером Oracle запрашивается обработка контрольной точки. Серверу Oracle нужно перенести отметку контрольной точки, чтобы не было необходимости в только что заполненном оперативном файле журнала повторного выполнения. Если ему не удастся это сделать до того, как возникнет необходимость в файле журнала повторного выполнения, выдается сообщение, что обработка контрольной точки не завершена (checkpoint not complete), и придется ждать завершения обработки.

Как видите, производительность процесса DBWn может иметь принципиальное значение. Если он недостаточно быстро записывает блоки для освобождения буферов, сеансам приходится ждать события FREE_BUFFER_WAITS, и показатель 'Write Complete Waits' начинает расти.

Можно сконфигурировать несколько (до десяти) процессов DBWn (DBW0 ... DBW9). В большинстве систем работает только один процесс записи блоков базы данных, но в больших, многопроцессорных системах имеет смысл использовать несколько. Если сконфигурировано более одного процесса DBWn, не забудьте также увеличить значение параметра инициализации DB_BLOCK_LRU_LATCHES. Он определяет количество защелок списков по давности использования, LRU lists (теперь, в версии 8i, их называют списками количества обращений — touch lists). Каждый процесс DBWn должен иметь собственный список. Если несколько процессов DBWn совместно используют один список блоков для записи на диск, они будут конфликтовать друг с другом при доступе к списку.

Обычно процесс DBWn использует асинхронный ввод-вывод для записи блоков на диск. При использовании асинхронного ввода-вывода процесс DBWn собирает пакет блоков для записи и передает его операционной системе. Процесс DBWn не ждет, пока ОС запишет блоки, — он собирает следующий пакет для записи. Завершив асинхронную запись, ОС уведомляет об этом процесс DBWn. Это позволяет процессу DBWn работать намного быстрее, чем при последовательном выполнении действий. В разделе "Подчиненные процессы" будет показано, как с помощью подчиненных процессов ввода-вывода можно эмулировать асинхронный ввод-вывод на платформах, где он не поддерживается.

И последнее замечание о процессе DBWn. Он, по определению, записывает блоки, разбросанные по всему диску, — процесс DBWn выполняет множество записей вразброс. В случае изменений будут изменяться разбросанные блоки индекса и блоки данных, достаточно случайно распределенные по диску. Процесс LGWR, напротив, выполняет в основном запись последовательных блоков в журнал повторного выполнения. Это — важное отличие и одна из причин, почему сервер Oracle имеет журнал повторного выполнения и отдельный процесс LGWR. Записи вразброс выполняются намного медленнее, чем последовательные записи. Имея грязные блоки в буферном кеше в SGA и процесс LGWR, записывающий большое количество последовательных блоков информации для восстановления измененных буферов, можно повысить производительность. Сочетание работы двух процессов — процесс DBWn медленно работает в фоновом режиме, тогда как процесс LGWR быстро выполняет работу для ожидающего пользователя — позволяет повысить общую производительность. Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода-вывода, чем надо (записывает в журнал и в файл данных), — записи в оперативный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск.

LGWR — запись журнала. Процесс LGWR отвечает за сброс на диск содержимого буфера журнала повторного выполнения, находящегося в области SGA. Он делает это:

раз в три секунды;

при фиксации транзакции;

при заполнении буфера журнала повторного выполнения на треть или при записи в него 1 Мбайта данных.

Поэтому создание слишком большого буфера журнала повторного выполнения не имеет смысла: сервер Oracle никогда не сможет использовать его целиком. Все журналы записываются последовательно, а не вразброс, как вынужден выполнять ввод-вывод процесс DBWn. Запись большими пакетами, как в этом случае, намного эффективнее, чем запись множества отдельных блоков в разные части файла. Это одна из главных причин выделения процесса LGWR и журнала повторного выполнения. Эффективность последовательной записи измененных байтов перевешивает расход ресурсов на дополнительный ввод-вывод. Сервер Oracle мог бы записывать блоки данных непосредственно на диск при фиксации, но это потребовало бы записи множества разбросанных блоков, а это существенно медленнее, чем последовательная запись изменений процессом LGWR.

ARCn — архивирование. Задача процесса ARCn — копировать в другое место оперативный файл журнала повторного выполнения, когда он заполняется процессом LGWR. Эти архивные файлы журнала повторного выполнения затем можно использовать для восстановления носителя. Тогда как оперативный журнал повторного выполнения используется для "исправления" файлов данных в случае сбоя питания (когда прекращается работа экземпляра), архивные журналы повторного выполнения используются для восстановления файлов данных в случае сбоя диска. Если будет потерян диск, содержащий файл данных /d01/oradata/ora8i/system.dbf, можно взять резервные копии за прошлую неделю, восстановить из них старую копию файла и попросить сервер применить оперативный журнал повторного выполнения и все архивные журналы, сгенерированные с момента создания этой резервной копии. Это "подтянет" файл по времени к остальным файлам в базе данных, и можно будет продолжить работу без потери данных.

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

BSP — сервер блоков. Этот процесс используется исключительно в среде Oracle Parallel Server (OPS). OPS — конфигурация Oracle, при которой несколько экземпляров монтируют и открывают одну и ту же базу данных. Каждый экземпляр Oracle в этом случае работает на своей машине в кластере, и все они имеют доступ для чтения и записи к одному и тому же набору файлов базы данных.

При этом буферные кеши в SGA экземпляров должны поддерживаться в согласованном состоянии. Для этого и предназначен процесс BSP. В ранних версиях OPS согласование достигалось с помощью выгрузки блока из кеша ('ping'). Если машине в кластере требовалось согласованное по чтению представление блока данных, заблокированного в исключительном режиме другой машиной, выполнялся обмен данными с помощью сброса на диск. В результате получалась очень дорогостоящая операция чтения данных. Сейчас, при наличии процесса BSP, обмен происходит из кеша в кеш через высокоскоростное соединение машин в кластере.

LMON — контроль блокировок. Этот процесс используется исключительно в среде OPS. Процесс LMON контролирует все экземпляры кластера для выявления сбоя экземпляра. Затем он вместе с диспетчером распределенных блокировок (Distributed Lock Manager — DLM), используемым аппаратным обеспечением кластера, восстанавливает глобальные блокировки, которые удерживаются сбойным экземпляром.

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

LCKn — блокирование. Процесс LCKn используется исключительно в среде OPS. Он подобен по функциям описанному выше процессу LMD, но обрабатывает запросы ко всем остальным глобальным ресурсам, кроме буферного кеша.

Служебные фоновые процессы

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

Служебных фоновых процессов — два. Один из них запускает посланные на выполнение задания. В СУБД Oracle встроена очередь пакетных заданий, позволяющая выполнять по расписанию однократные или периодические задания. Другой процесс поддерживает и обрабатывает таблицы очереди, используемые средствами расширенной поддержки очередей (Advanced Queuing — AQ). Средства AQ обеспечивают встроенные возможности обмена сообщениями между сеансами базы данных.

Эти процессы можно увидеть в среде ОС UNIX, как и любой другой фоновый процесс, с помощью команды ps. В представленных ранее результатах выполнения команды ps можно видеть, что у меня в экземпляре работает один процесс очереди заданий (ora_snp0_ora8I) и ни одного процесса очереди.

SNPn — обработка снимков (очереди заданий). Сейчас можно сказать, что имя для процесса SNPn выбрано неудачно. В версии 7.0 сервера Oracle впервые появилась поддержка репликации. Это делалось с помощью объекта базы данных, известного как моментальный снимок (snapshot). Внутренним механизмом для обновления или приведения к текущему состоянию моментальных снимков был SNPn — процесс обработки снимков (snapshot process). Этот процесс контролировал таблицу заданий, по которой определял, когда необходимо обновлять моментальные снимки в системе. В Oracle 7.1 корпорация Oracle открыла это средство для общего доступа через пакет DBMS_JOB. То, что было связано с моментальными снимками в версии 7.0, стало "очередью заданий" в версии 7.1 и последующих. Со временем имена параметров для управления очередью (как часто ее надо проверять и сколько процессов может быть в очереди) изменились со SNAPSHOT_REFRESH_INTERVAL и SNAPSHOT_REFRESH_PROCESSES на JOB_QUEUE_INTERVAL и JOB_QUEUE_PROCESSES. А вот имя процесса операционной системы не изменилось.

Можно запускать до 36 процессов очереди заданий. Они именуются SNP0, SNP1, ..., SNP9, SNPA, ..., SNPZ. Эти процессы очередей заданий интенсивно используются при репликации в ходе обновления моментального снимка или материализованного представления. Разработчики также часто используют их для запуска отдельных (фоновых) или периодически выполняющихся заданий. Например, далее в книге будет показано, как использовать очереди заданий для существенного ускорения обработки: за счет дополнительной работы можно сделать намного приятнее среду для пользователя (аналогично тому, как сделано в самом сервере Oracle при использовании процессов LGWR и DBWn).

Процессы SNPn сочетают в себе особенности как разделяемого, так и выделенного сервера: обрабатывают несколько заданий, но памятью управляют как выделенный сервер (область UGA находится в области PGA процесса). Процесс очереди заданий выполняет в каждый момент времени только одно задание. Вот почему необходимо несколько процессов, если требуется выполнять несколько заданий одновременно. На уровне заданий не поддерживаются потоки или вытеснение. Запущенное задание выполняется, пока не будет выполнено (или не произойдет сбой). В приложении А мы более детально рассмотрим пакет DBMS_JOB и нетрадиционное использование очереди заданий.

QMNn — контроль очередей. Процесс QMNn по отношению к таблицам AQ выполняет ту же роль, что и процесс SNPn по отношению к таблице заданий. Этот процесс контролирует очереди и уведомляет ожидающие сообщений процессы о том, что доступно сообщение. Он также отвечает за распространение очередей — возможность переместить сообщение, поставленное в очередь в одной базе данных, в другую базу данных для извлечения из очереди.

Монитор очередей — это необязательный фоновый процесс. Параметр инициализации AQ_TM_PROCESS позволяет создать до десяти таких процессов с именами QMN0, ..., QMN9. По умолчанию процессы QMNn не запускаются.

EMNn — монитор событий. Процессы EMNn — часть подсистемы расширенной поддержки очередей. Они используются для уведомления подписчиков очереди о сообщениях, в которых они могут быть заинтересованы. Это уведомление выполняется асинхронно. Имеются функции Oracle Call Interface (OCI) для регистрации обратного вызова, уведомляющего о сообщении. Обратный вызов (callback) — это функция в программе OCI, которая вызывается автоматически при появлении в очереди определенного сообщения. Фоновый процесс EMNn используется для уведомления подписчика. Процесс EMNn запускается автоматически при выдаче первого уведомления в экземпляре. После этого приложение может явно вызвать message_receive(dequeue) для извлечения сообщения из очереди.