•Серверные процессы. Они выполняют запросы клиентов. Мы уже затрагивали тему
выделенных и разделяемых серверов. И те, и другие относятся к серверным про-
цессам.
• Фоновые процессы. Это процессы, которые начинают выполняться при запуске
экземпляра и решают различные задачи поддержки базы данных, такие как за-
пись блоков на диск, поддержка активного журнала повторного выполнения, уда-
ление прекративших работу процессов и т.д.
• Подчиненные процессы. Они подобны фоновым процессам, но выполняют, кор-
ме того, действия от имени фонового или серверного процесса.
Серверные процессы
Выделенные и разделяемые серверы решают одну и ту же задачу: обрабатывают пе-
редаваемые им SQL-операторы. При получении запроса SELECT * FROM EMP имен-
но выделенный/разделяемый сервер Oracle будет разбирать его и помещать в разделяе-
мый пул (или находить соответствующий запрос в разделяемом пуле). Именно этот
процесс создает план выполнения запроса. Этот процесс реализует план запроса, нахо-
дя необходимые данные в буферном кэше или считывая данные в буферный кэш с дис-
ка. Такие серверные процессы можно назвать "рабочими лошадками" СУБД. Часто имен-
но они потребляют основную часть процессорного времени в системе, поскольку
выполняют сортировку, суммирование, соединения - в общем, почти все.
В режиме выделенного сервера имеется однозначное соответствие между клиентс-
кими сеансами и серверными процессами (или потоками).
С клиентским приложением скомпонованы библиотеки Oracle. Они обеспечивают
функциональный интерфейс (Application Program Interface - API) для взаимодействия
с базой данных. Функции API "знают", как передавать запрос к базе данных и обраба-
тывать возвращаемый курсор. Они обеспечивают преобразование запросов пользовате-
ля в передаваемые по сети пакеты, обрабатываемые выделенным сервером. Эти функ-
ции обеспечивает компонент Net8 - сетевое программное обеспечение/протокол,
используемое Oracle для клиент/серверной обработки (даже в n-звенной архитектуре есть
место для клиент/серверного взаимодействия). Сервер Oracle использует такую архитек-
туру, даже если протокол Net8 не нужен. То есть, когда клиент и сервер работают на
одной и той же машине, используется эта двухпроцессорная (известная также как двухза-
дачная - two-task) архитектура. Эта архитектура обеспечивает два преимущества.
• Удаленное выполнение. Клиентское приложение, естественно, может работать не
на той машине, где работает СУБД.
• Изолирование адресных пространств. Серверный процесс имеет доступ для чте-
ния и записи к области SGA. Ошибочный указатель в клиентском процессе мо-
жет повредить структуры данных в области SGA, если клиентский и серверный
процессы физически взаимосвязаны.
Разделяемый серверный процесс. Для подключения к серверному процессу этого типа обя-
зательно используется протокол Net8, даже если клиент и сервер работают на одной ма-
шине, - нельзя использовать режим MTS без процесса прослушивания Net8. Как уже
описывалось ранее в этом разделе, клиентское приложение подключается к процессу
прослушивания Net8 и перенаправляется на процесс-диспетчер. Диспетчер играет роль
канала передачи информации между клиентским приложением и разделяемым сервер-
ным процессом. Ниже представлена схема подключения к базе данных через разделяе-
мый сервер:
клиентские приложения со скомпонованными в них библиотеками Oracle
физически подключаются к диспетчеру MTS. Диспетчеров MTS для любого экземпляра
можно сгенерировать несколько, но часто для сотен и даже тысяч пользователей исполь-
зуется один диспетчер. Диспетчер отвечает за получение входящих запросов от клиент-
ских приложений и их размещение в очереди запросов в области SGA. Первый свобод-
ный разделяемый серверный процесс, по сути, ничем не отличающийся от выделенного
серверного процесса, выберет запрос из очереди и подключится к области UGA соот-
ветствующего сеанса (прямоугольника с 'S' на представленной выше схеме). Разделяе-
мый сервер обработает запрос и поместит полученный при его выполнении результат в
очередь ответов. Диспетчер постоянно следит за появлением результатов в очереди и
передает их клиентскому приложению. С точки зрения клиента нет никакой разницы
между подключением к выделенному серверу и подключением в режиме MTS, - они
работают одинаково. Различие возникает только на уровне экземпляра.
Фоновые процессы
Экземпляр Oracle состоит из двух частей: области SGA и набора фоновых процессов. Фоновые процессы выполняют рутинные задачи сопровождения, обеспечивающие
работу СУБД. Есть два класса фоновых процессов: предназначенные исключительно для решения
конкретных задач (как только что описанные) и решающие множество различных за-
дач.
Фоновые процессы, предназначенные для решения
конкретных задач
На следующей схеме представлены фоновые процессы экземпляра Oracle, имеющие
конкретное назначение:
Вы не обязательно увидите все эти процессы сразу после запуска своего экземпляра,
но большинство из них работает в каждом экземпляре.
PMON - монитор процессов
Этот процесс отвечает за очистку после нештатного прекращения подключений.
Например, если выделенный сервер "падает" или, получив сигнал, прекращает работу,
именно процесс PMON освобождает ресурсы. Процесс PMON откатит незафиксиро-
ванные изменения, снимет блокировки и освободит ресурсы в области SGA, выделен-
ные прекратившему работу процессу.
Процесс PMON следит за всеми процессами Oracle и либо перезапускает их, либо пре-
кращает работу экземпляра, в зависимости от ситуации.
Еще одна функция процесса PMON в экземпляре (версия Oracle 8i) - регистриро-
вать экземпляр в процессе прослушивания протокола Net8.
SMON - монитор системы
SMON - это процесс, занимающийся всем тем, от чего "отказываются" остальные
процессы. Это своего рода "сборщик мусора" для базы данных. Вот некоторые из реша-
емых им задач.
• Очистка временного пространства.
• Восстановление после сбоев.
• Дефрагментация свободного пространства.
• Восстановление транзакций, затрагивающих недоступные файлы.
• Восстановление сбойного экземпляра в OPS.
• Очистка таблицы OBJ$.
• Сжатие сегментов отката.
• "Отключение" сегментов отката.
RECO - восстановление распределенной базы данных
Процесс RECO имеет очень конкретную задачу: он восстанавливает транзакции,
оставшиеся в готовом состоянии из-за сбоя или потери связи в ходе двухэтапной фикса-
ции (2PC). 2PC - это распределенный протокол, позволяющий неделимо фиксировать
изменения в нескольких удаленных базах данных.
CKPT - обработка контрольной точки
Процесс обработки контрольной точки вовсе не обрабатывает ее, как можно пред-
положить по названию, - это делает процесс DBWn. Процесс CKPT просто содействует обработке контрольной точки, обновляя заголовки файлов данных.
DBWn - запись блоков базы данных
Процесс записи блоков базы данных (Database Block Writer - DBWn) - фоновый
процесс, отвечающий за запись измененных блоков на диск. Процесс DBWn записыва-
ет измененные блоки из буферного кэша, чтобы освободить пространство в кэше (что-
бы освободить буферы для чтения других данных) или в ходе обработки контрольной
точки (чтобы перенести вперед позицию в активном файле журнала повторного выпол-
нения, с которой сервер Oracle начнет чтение при восстановлении экземпляра после
сбоя).
LGWR - запись журнала
Процесс LGWR отвечает за сброс на диск содержимого буфера журнала повторного
выполнения, находящегося в области SGA. Он делает это:
• раз в три секунды;
• при фиксации транзакции;
• при заполнении буфера журнала повторного выполнения на треть или при запи-
си в него 1 Мбайт данных.
ARCn - архивирование
Задача процесса ARCn - копировать в другое место активный файл журнала повтор-
ного выполнения, когда он заполняется процессом LGWR. Эти архивные файлы жур-
нала повторного выполнения затем можно использовать для восстановления носителя.
BSP - сервер блоков
Этот процесс используется исключительно в среде Oracle Parallel Server (OPS). OPS -
конфигурация Oracle, при которой несколько экземпляров монтируют и открывают одну
и ту же базу данных. Каждый экземпляр Oracle в этом случае работает на своей машине
в кластере, и все они имеют доступ для чтения и записи к одному и тому же набору
файлов базы данных.
При этом буферные кэши в SGA экземпляров должны поддерживаться в согласован-
ном состоянии. Для этого и предназначен процесс BSP.
LMON - контроль блокировок
Этот процесс используется исключительно в среде OPS. Процесс LMON контроли-
рует все экземпляры кластера для выявления сбоя экземпляра. Затем он вместе с дис-
Этот процесс используется исключительно в среде OPS. Процесс LMD управляет
глобальными блокировками и глобальными ресурсами для буферного кэша в кластер-
ной среде.
LCKn - блокирование
Процесс LCKn используется исключительно в среде OPS. Он подобен по функциям
описанному выше процессу LMD, но обрабатывает запросы ко всем остальным глобаль-
ным ресурсам, кроме буферного кэша.
Служебные фоновые процессы
Эти фоновые процессы необязательны - они запускаются в случае необходимости.
Они реализуют средства, необязательные для штатного функционирования базы данных.
Использование этих средств инициируется явно или косвенно, при использовании воз-
можности, требующей их запуска.
Служебных фоновых процессов - два. Один из них запускает посланные на выпол-
нение задания. Другой процесс под-
держивает и обрабатывает таблицы очереди, используемые средствами расширенной
поддержки очередей (Advanced Queuing - AQ).
SNPn - обработка снимков (очереди заданий)
Процессы SNPn сочетают в себе особенности как разделяемого, так и выделенного
сервера: обрабатывают несколько заданий, но памятью управляют как выделенный сер-
вер (область UGA находится в области PGA процесса). Процесс очереди заданий выпол-
няет в каждый момент времени только одно задание. Вот почему необходимо несколь-
ко процессов, если требуется выполнять несколько заданий одновременно.
QMNn - монитор очередей
Процесс QMNn по отношению к таблицам AQ выполняет ту же роль, что и процесс
SNPn по отношению к таблице заданий. Этот процесс контролирует очереди и уведом-
ляет ожидающие сообщений процессы о том, что доступно сообщение. Он также отве-
чает за распространение очередей - возможность переместить сообщение, поставлен-
ное в очередь в одной базе данных, в другую базу данных для извлечения из очереди. Монитор очередей - это необязательный фоновый процесс.
EMNn - монитор событий
Процессы EMNn - часть подсистемы расширенной поддержки очередей. Они ис-
пользуются для уведомления подписчиков очереди о сообщениях, в которых они могут
быть заинтересованы. Это уведомление выполняется асинхронно.
Подчиненные процессы
Теперь мы готовы рассмотреть последний класс процессов Oracle - подчиненные
процессы. В сервере Oracle есть два типа подчиненных процессов - ввода/вывода (I/O
slaves) и параллельных запросов (Parallel Query slaves).
Подчиненные процессы ввода/вывода
Подчиненные процессы ввода/вывода используются для эмуляции асинхронного
ввода/вывода в системах или на устройствах, которые его не поддерживают. Например,
ленточные устройства (чрезвычайно медленно работающие) не поддерживают асинхрон-
ный ввод/вывод. Как и в случае действительно асинхронного ввода/вывода, процесс, записывающий на устройство, накапливает большой объем данных в виде па-
кета и отправляет их на запись. Об их успешной записи процесс (на этот раз - подчи-
ненный процесс ввода/вывода, а не ОС) сигнализирует исходному вызвавшему процес-
су, который удаляет этот пакет из списка данных, ожидающих записи.
Подчиненные процессы параллельных запросов
Речь идет
о возможности создавать для SQL-операторов типа SELECT, CREATE TABLE, CREATE
INDEX, UPDATE и т.д. план выполнения, состоящий из нескольких планов, которые
можно выполнять одновременно. Результаты выполнения этих планов объединяются.
Это позволяет выполнить операцию за меньшее время, чем при последовательном вы-
полнении. Например, если имеется большая таблица, разбросанная по десяти различ-
ным файлам данных, 16-процессорный сервер, и необходимо выполнить к этой табли-
це запрос, имеет смысл разбить план выполнения этого запроса на 16 небольших частей
и полностью использовать возможности сервера.