Oracle для профессионалов
Серверные процессы
Мы уже бегло рассматривали эти процессы ранее при обсуждении выделенных и разделяемых серверов. Здесь мы еще раз опишем два вида серверных процессов и более детально рассмотрим их архитектуру.
Выделенные и разделяемые серверы решают одну и ту же задачу: обрабатывают передаваемые им SQL-операторы. При получении запроса SELECT * FROM EMP
именно выделенный/разделяемый сервер Oracle будет разбирать его и помещать в разделяемый пул (или находить соответствующий запрос в разделяемом пуле). Именно этот процесс создает план выполнения запроса. Этот процесс реализует план запроса, находя необходимые данные в буферном кеше или считывая данные в буферный кеш с диска. Такие серверные процессы можно назвать "рабочими лошадками" СУБД. Часто именно они потребляют основную часть процессорного времени в системе, поскольку выполняют сортировку, суммирование, соединения — в общем, почти все.
В режиме выделенного сервера имеется однозначное соответствие между клиентскими сеансами и серверными процессами (или потоками). Если имеется 100 сеансов на UNIX-машине, будет 100 процессов, работающих от их имени. Графически это можно представить так:
...
С клиентским приложением скомпонованы библиотеки Oracle. Они обеспечивают функциональный интерфейс (Application Program Interface — API) для взаимодействия с базой данных. Функции API "знают", как передавать запрос к базе данных и обрабатывать возвращаемый курсор. Они обеспечивают преобразование запросов пользователя в передаваемые по сети пакеты, обрабатываемые выделенным сервером. Эти функции обеспечивает компонент Net8 — сетевое программное обеспечение/протокол, используемое Oracle для клиент-серверной обработки (даже в n-звенной архитектуре есть место для клиент-серверного взаимодействия). Сервер Oracle использует такую архитектуру, даже если протокол Net8 не нужен. То есть, когда клиент и сервер работают на одной и той же машине, используется эта двухпроцессная (известная также как двухзадачная — two-task) архитектура. Эта архитектура обеспечивает два преимущества.
Ранее в этой главе мы рассматривали "порождение", или создание, этих серверных процессов процессом прослушивания Oracle Net8 Listener. Не будем снова возвращаться к этому процессу, но коротко рассмотрим, что происходит, если процесс прослушивания не задействован. Механизм во многом аналогичен, но вместо создания выделенного сервера процессом прослушивания с помощью вызовов fork()/exec()
в ОС UNIX или вызова IPC (Inter Process Communication), как это происходит в Windows, процесс создается непосредственно клиентским процессом. Это можно четко увидеть в ОС UNIX:
ops$tkyte@ORA8I.WORLD> select a.spid dedicated_server, 2 b.process clientpid 3 from v$process a, v$session b 4 where a.addr = b.paddr 5 and b.audsid = userenv('sessionid') 6 /
DEDICATED CLIENTPID --------- --------- 7055 7054
ops$tkyte@ORA8I.WORLD> !/bin/ps -lp 7055 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 8 S 30174 7055 7054 0 41 20 61ac4230 36815 639b1998 ? 0:00 oracle
ops$tkyte@ORA8I.WORLD> !/bin/ps -lp 7054 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 8 S 12997 7054 6783 0 51 20 63eece30 1087 63eecea0 pts/7 0:00 sqlplus
Я использовал запрос для определения идентификатора процесса (PID) моего выделенного сервера (столбец SPID в представлении V$PROCESS — это идентификатор процесса операционной системы, использовавшегося для выполнения запроса). Кроме того, в столбце PROCESS представления V$SESSION
находится идентификатор клиентского процесса, подключившегося к базе данных. С помощью команды ps можно явно показать, что PPID (Parent Process ID — идентификатор родительского процесса) моего выделенного сервера соответствует процессу SQL*Plus. В данном случае именно утилита SQL*Plus создала выделенный сервер с помощью системных вызовов fork()
и exec().
Теперь давайте более детально рассмотрим другой тип серверных процессов — разделяемый серверный процесс. Для подключения к серверному процессу этого типа обязательно используется протокол Net8, даже если клиент и сервер работают на одной машине, — нельзя использовать режим MTS без процесса прослушивания Net8. Как уже описывалось ранее в этом разделе, клиентское приложение подключается к процессу прослушивания Net8 и перенаправляется на процесс-диспетчер. Диспетчер играет роль канала передачи информации между клиентским приложением и разделяемым серверным процессом. Ниже представлена схема подключения к базе данных через разделяемый сервер:
...
Как видите, клиентские приложения со скомпонованными в них библиотеками Oracle физически подключаются к диспетчеру MTS. Диспетчеров MTS для любого экземпляра можно сгенерировать несколько, но часто для сотен и даже тысяч пользователей используется один диспетчер. Диспетчер отвечает за получение входящих запросов от клиентских приложений и их размещение в очереди запросов в области SGA. Первый свободный разделяемый серверный процесс, по сути, ничем не отличающийся от выделенного серверного процесса, выберет запрос из очереди и подключится к области UGA соответствующего сеанса. Разделяемый сервер обработает запрос и поместит полученный при его выполнении результат в очередь ответов. Диспетчер постоянно следит за появлением результатов в очереди и передает их клиентскому приложению. С точки зрения клиента нет никакой разницы между подключением к выделенному серверу и подключением в режиме MTS, — они работают одинаково. Различие возникает только на уровне экземпляра.
