клиентское приложение

выделенный фвер

С клиентским приложением скомпонованы библиотеки Oracle. Они обеспечивают функциональный интерфейс (Application Program Interface - API) для взаимодействия с базой данных. Функции API знают , как передавать запрос к базе данных и обрабатывать возвращаемый курсор. Они обеспечивают преобразование запросов пользователя в передаваемые по сети пакеты, обрабатываемые выделенным сервером. Эти функции обеспечивает компонент Net8 - сетевое программное обеспечение/протокол, используемое Oracle для клиент/серверной обработки (даже в n-звенной архитектуре есть место для клиент/серверного взаимодействия). Сервер Oracle использует такую архитектуру, даже если протокол Net8 не нужен. То есть, когда клиент и сервер работают на одной и той же машине, используется эта двухпроцессорная (известная также как двухза-дачная - two-task) архитектура. Эта архитектура обеспечивает два преимущества.

Удаленное в1нолнение. Клиентское приложение, естественно, может работать не на той машине, где работает СУБД.

Изолирование адресн1х нространств. Серверный процесс имеет доступ для чтения и записи к области SGA. Ошибочный указатель в клиентском процессе может повредить структуры данных в области SGA, если клиентский и серверный процессы физически взаимосвязаны.

Ранее в этой главе мы рассматривали порождение , или создание, этих сервернтх процессов процессом прослушивания Oracle Net8 Listener. He будем снова возвращаться к этому процессу, но коротко рассмотрим, что происходит, если процесс прослушивания не задействован. Механизм во многом аналогичен, но вместо создания в]делен-ного сервера процессом прослушивания с помощью вызовов 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

DCED CLIENTPID

userenv(sessionid)

7055

7054

ops$tkyte@ORA8I.WORLD> F S DID PID PPID 8 S 30174 7055 7054

!/bin/pa -lp 7055

С PRI HI ADDR SZ WCHAN TTY TIME CMD

0 41 20 61ac4230 36815 639b1998 ? 0:00 oracle

ops$tkyte@ORA8I.WORLD> !/bin/pa -lp 7054 F S UID PID PPID С PRI N1 ADDR 8 S 12997 7054 6783 0 51 20 63eece30

SZ WCHAN TTY TIME CMD 1087 63eece30 pts/7 0:00 sqlplus

Я использовал запрос для определения идентификатора процесса (PID) моего выделенного сервера (столбец SPID в представлении V$PROCESS - это идентификатор процесса операционной системы, использовавшегося для выполнения запроса). Кроме того, в столбце PROCESS представления V$SESSION находится идентификатор клиентского процесса, подключившегося к базе данных. С помощью команды ps можно явно показать, что PPID (Parent Process ID - идентификатор родительского процесса) моего выделенного сервера соответствует процессу SQL*Plus. В данном случае именно утилита SQL*Plus создала выделенный сервер с помощью системных вызовов forkO и exec().

Теперь давайте более детально рассмотрим другой тип серверных процессов - разделяемый серверный процесс. Для подключения к серверному процессу этого типа обязательно используется протокол Net8, даже если клиент и сервер работают на одной машине, - нельзя использовать режим MTS без процесса прослушивания Net8. Как уже описывалось ранее в этом разделе, клиентское приложение подключается к процессу прослушивания Net8 и перенаправляется на процесс-диспетчер. Диспетчер играет роль канала передачи информации между клиентским приложением и разделяемым серверным процессом. Ниже представлена схема подключения к базе данных через разделяемый сервер:

Выделенный и разделяемый сервер

Прежде чем перейти к остальным процессам, давайте обсудим, почему поддерживается два режима подключения и когда лучше использовать каждый из них. Режим выделенного сервера - наиболее широко используемый способ подключения к СУБД Oracle для всех приложений, использующих SQL-запросы. Режим выделенного сервера проще настроить и он обеспечивает самый простой способ подключения. При этом требуется минимальное конфигурирование. Настройка и конфигурирование режима MTS, хотя и несложный, но дополнительный шаг. Основное различие между этими режимами, однако, не в настройке. Оно связано с особенностями работы. При использовании выделенного сервера имеется соответствие один к одному между клиентским сеансом и серверным процессом. В режиме MTS соответствие - многие к одному (много клиентов и один разделяемый сервер). Как следует из названия, разделяемый сервер - общий ресурс, а выделенный - нет. При использовании общего ресурса необходимо стараться не монополизировать его надолго. Как б1ло показано в главе 1, в примере с компонентами EJB, запускавшими продолжительную хранимую процедуру, монополизация этого ресурса может приводить как бы к зависанию системы. На представленной выше схеме имеется два разделяемых сервера. При наличии трех клиентов, более-менее одновременно пытающихся запустить 45-секундный процесс, два из них получат результат через 45 секунд, а третий - через 90 секунд. Правило номер один для режима MTS: убедитесь, что транзакции выполняются быстро. Они могут выполняться часто, но должны быть короткими (что обычно и бывает в системах ООТ). В противном случае будут наблюдаться все признаки замедления работы системы из-за монополизации общих ресурсов несколькими процессами. В экстремальных случаях, если все разделяемые серверы заняты, система зависает .

Поэтому режим MTS очень хорошо подходит для систем класса ООТ, характеризующихся короткими, но частыми транзакциями. В системе класса ООТ транзакции выполняются за миллисекунды, - ни одно действие не требует для выполнения более чем доли секунды. Режим MTS не подходит, однако, для хранилища данных. В такой системе выполняются запросы продолжительностью одна, две, пять и более минут. Для режима MTS это смертельно . В системе, где 90 процентов задач относятся к классу ООТ,

Как видите, клиентские приложения со скомпонованными в них библиотеками Oracle физически подключаются к диспетчеру MTS. Диспетчеров MTS для любого экземпляра можно сгенерировать несколько, но часто для сотен и даже тысяч пользователей используется один диспетчер. Диспетчер отвечает за получение входящих запросов от клиентских приложений и их размещение в очереди запросов в области SGA. Первый свободный разделяемый серверный процесс, по сути, ничем не отличающийся от выделенного серверного процесса, выберет запрос из очереди и подключится к области UGA соответствующего сеанса (прямоугольника с S на представленной выше схеме). Разделяемый сервер обработает запрос и поместит полученный при его выполнении результат в очередь ответов. Диспетчер постоянно следит за появлением результатов в очереди и передает их клиентскому приложению. С точки зрения клиента нет никакой разницы между подключением к выделенному серверу и подключением в режиме MTS, - они работают одинаково. Различие возникает только на уровне экземпляра.