Shared server что это
Конфигурация dedicated или shared сервер. Каковы критерии выбора?
Каковы критерии выбора и как переключиться с dedicated на shared и наоборот во время эксплуатации, если ранее был сделан неправильный выбор?
1 ответ 1
Oracle БД создаёт серверный процесс для обработки запросов пользовательских процессов подключенных к определённой инстанции.
Серверный процесс: на *NIX это процесс на системном уровне (начиная с 12c может бытъ сконфигурирован как поток). Под WIN это всегда поток.
Серверный процесс может бытъ:
dedicated (выделенный), обслуживает только один пользовательский процесс
Распределённый сервер был введён в версии 7, когда системные ресурсы (в первую очередь, память) были очень дороги и этим достигалась их экономия. В настоящее время эта экономия больше не существенна. В случае выделенного сервера отпадает оверхед на респределение (dispatch) и поэтому эта конфигурация более производительна.
Несмотря на то, что в офф. документации shared сервер всё ешё упомянут как предпочтительный, всё же конфигурация как dedicated сервер является более целесообразной в 95% случаев.
Распределённый сервер лучше использовать, если много клиентских процессов, которые не используют постояннный коннект к БД, т.е. вызывается подключение, производится обновление одной или нескольких таблиц и далее производится явное или неявное разединение. Каждый, кто немного знаком с современными программными архитектурами, заметит, что подобный сценарий уже изжил себя.
Пример того, что будет создано на системном уровне для выделенного сервера (для лучшего понимания в связанном вопросе):
вторник, 22 сентября 2009 г.
В подавляющем большинстве случаев мы используем при работе с базой режим DEDICATED servers. То есть, для каждого соединения сервер запускает выделенный серверный процесс.
Эта схема хороша для чистого клиент-сервера, при условии, что достаточно памяти для запуска всех без исключения процессов и при этом соединения держатся достаточно долго, для того, чтобы не приходилось сессии разрывать и устанавливать заново.
Существует, однако, достаточно распространенная сейчас архитектура приложений, когда такой режим очень нехорош с точки зрения накладных расходов, и, соответственно, ведет к ухудшению отклика системы.
Это Web-приложения, работающие с базой. mod_plsql работает как Oracle*Net клиент, и, при каждом HTTP-вызове устанавливает и разрывает соединение с базой. Это ведет к большому количеству запусков выделенных процессов, высокому переключению контекстов и, в конечном итоге, ухудшает отклик системы.
Все бы ничего, но при резких скачках нагрузки и фиксированных настройках Web-листенера и базы статистика фиксирует достаточно часто появляющиеся ошибки «503: Server busy». Что в принципе говорит о том, что база не успевает реагировать на запросы ввиду того, что приходится быстро запускать серверные процессы в достаточно большом количестве.
Считается, однако, что Shared-сервер непонятно, как сконфигурировать и как использовать.
На самом деле все очень просто.
Возьмем реальный пример базы, которая находится на одном хосте с Web-листенером. Допустим, что мы хотим ее перевести для Web-соединений (и только для них) в режим Shared server. Оставив сервис DEDICATED для административных целей.
Как мы это сделаем?
Во-первых, выключим существующие диспетчеры по умолчанию:
alter system set dispatchers=»;
Делаем мы это для того, чтобы не плодить толпу слушающих диспетчеров, потому что нижеприведенная команда добавляет диспетчеры к существующим. По умолчанию в десятке есть диспетчер XDB, он нам не больно-то и нужен. Посему сбросим его и будем задавать собственные диспетчеры.
Затем приступим к конфигурированию собственно Shared-сервиса базы:
alter system set large_pool_size=8m scope=both;
alter system set dispatchers=»(ADDRESS=(PROTOCOL=tcp)(PORT=16384))(DISPATCHERS=2)» scope=both;
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Однако теперь нужно сделать две вещи. Во-первых, настроить листенер. В нашем случае настройка должна быть не вполне обычная:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = SUN10.domain.com)
(SID_NAME = SUN10)
(ORACLE_HOME = /export/home/OraHome1/app/oracle/product/10.2.0)
)
(SID_DESC =
(GLOBAL_DBNAME = SUN10_XPT.domain.com)
(SID_NAME = SUN10)
(ORACLE_HOME = /export/home/OraHome1/app/oracle/product/10.2.0)
)
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /export/home/OraHome1/app/oracle/product/10.2.0)
(PROGRAM = extproc)
)
)
Во-вторых, нужно настроить mod_plsql для соединения не с DEDICATED, а с SHARED-сервером, ну и для остальных клиентов базы разделить сервисы, чтобы, скажем, администраторы всегда ходили на DEDICATED-сервис.
Изменим одну запись в dads.conf и перезапустим Web-сервер:
#PlsqlDatabaseConnectString localhost:1521:SUN10.domain.com ServiceNameFormat
PlsqlDatabaseConnectString localhost:16384:SUN10_XPT.domain.com ServiceNameFormat
Для решения последней задачи добавим в tnsnames.ora запись о shared-сервисе и изменим запись dedicated-сервиса:
SUN10 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = SUN10.domain.com)
(SERVER=dedicated)
)
)
SUN10_XPT =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 16384))
)
(CONNECT_DATA =
(SERVICE_NAME = SUN10_XPT.domain.com)
(SERVER=shared)
)
)
В общем-то, это все. Осталось проверить, работает ли сервис:
oracle @ hostname
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=www.domain.com)(PORT=1521)(QUEUESIZE=10)(SEND_BUF_SIZE=65536)(RECV_BUF_SIZE=65536)))
Services Summary.
Service «PLSExtProc» has 1 instance(s).
Instance «PLSExtProc», status UNKNOWN, has 1 handler(s) for this service.
Handler(s):
«DEDICATED» established:0 refused:0
LOCAL SERVER
Service «SUN10.domain.com» has 2 instance(s).
Instance «SUN10», status UNKNOWN, has 1 handler(s) for this service.
Handler(s):
«DEDICATED» established:0 refused:0
LOCAL SERVER
Instance «SUN10», status READY, has 2 handler(s) for this service.
Handler(s):
«D000» established:0 refused:0 current:8 max:992 state:ready
DISPATCHER
(ADDRESS=(PROTOCOL=tcp)(HOST=www.domain.com)(PORT=16384))
«DEDICATED» established:0 refused:0 state:ready
LOCAL SERVER
Service «SUN10_XPT.domain.com» has 2 instance(s).
Instance «SUN10», status UNKNOWN, has 1 handler(s) for this service.
Handler(s):
«DEDICATED» established:0 refused:0
LOCAL SERVER
Instance «SUN10», status READY, has 2 handler(s) for this service.
Handler(s):
«D000» established:0 refused:0 current:8 max:992 state:ready
DISPATCHER
(ADDRESS=(PROTOCOL=tcp)(HOST=www.domain.com)(PORT=16384))
«DEDICATED» established:0 refused:0 state:ready
LOCAL SERVER
The command completed successfully
Работает. Посмотрим представления базы данных:
SQL> select dispatcher, status, queue from v$circuit;
SQL> select name, circuit, idle, busy, requests from v$shared_server;
Использование архитектуры Shared Server Architecture
Стандартная архитектура выделенного сервера требует чтобы listener создавал выделенный серверный процесс для каждого подключения к экземпляру БД. Эти серверные процессы существуют пока сессия не будет завершена. В Unix подобных ОС серверные процессы это обычные системные процессы; в Windows это потоки внутри одного процесса ORACLE.EXE. Такая архитектура не поддерживает масштабирование для поддержки большого количества процессов на некоторых платформах. Альтернативой является архитектура общего сервера, ранее известная как многопоточный сервер (MTS).
Ограничения архитектуры выделенного сервера
Чем больше пользователей подключаеся к экземпляру БД, тем больше запускается серверных процессов. Это не проблема, так как Oracle продумал эту ситуацию. Listener может запустить столько процессов, сколько необходимо, несмотря на то что могут быть ограничения по скорости запуска сессий. Если происходит большое количество одновременных запросов на соединение – listener будет помещать их в очередь. Этого можно избежать запустив несколько listener-ов на разных портах и распределяя нагрузку между ними. Когда сессия установлена, PMON процесс может обслуживать сколько угодно сессий. Но операционная система может иметь ограничения на количество запущенных процессов, проблемы при операции context switch и работе с памятью.
Компьютер может выполнять только одну задачу в одим момент времени (если у вас SMP сервер, то тогда каждый процессов выполняет по одной задаче). Операционная система эмулирует параллельное выполнение используя алгоритм распределения тактов процессора между всему текущими задачами. Этот алгоритм, известный как алгоритм распределения времени (timeslicing или timesharing) используется для распределения циклов процессора между процессами для выполнения. Переключения процессора с выполнения одной задачи на другую называется операцией переключения контекста (context switch). Эти операции очень дорогостоящие для производительности: операционной системе необходимо выполнить много работы для восстановления состоянии процесса при его активации и сохранения состояния процесса который становится неактивным. Чем больше пользователей подключается к экземпляру БД, тем чаще будет происходить операция context switch. В зависимости от операционной системы это может привести к падению производительности вашего сервера. ОС мейнфреймов могут выполнять операцию context switch для десятков тысяч процессов безо всяких проблема, но более новые (и простые) операционные системы как Unix и Windows не слишком хороши при работе с тысячами (даже сотнями) одновременно запущенными процессами. Производительность падает так как большая часть вычислительной мощности тратится на управление операциями смены контекста, и малая часть остаётся для собственно выполнения работы.
Так же могут возникать проблемы с памятью при подключении новых и новых подключений. Сами по себе серверные процесса не представляют опасности, так как во всех современных ОС используется общая память для процесса запущенного больше чем один раз, т.е. запуск тысячи процессов потребляет столько же памяти сколько запуск одного процесса. А проблема кроется в program global area (PGA). PGA — это участок памяти выделяемый для каждого процесса для поддержки состояния сессии и выполнения такой работы как к примеру сортировка данных. PGA не может использовать общую память – в ней содержатся данные уникальные для каждой сессии. Во многих опреационных системах при отстутствии свободной памяти используется файл подкачки или разбитое место на диске и страницы из памяти записываются на диск для освобождения места для данных рабочего процесса. Когда данные которые записаны на диск опять нужны в памяти, снова неиспользуемые в текущий момент времени страницы памяти записываются на диск а нужные данные считываются с диска в освободившееся пространство. Если такие операции перекачки информации происходят часто – это катастрофически снижает производительность. Так как PGA выделяется для каждой сессии, то чем больше пользователей будет подключаться, тем чаще (при остуствии достаточного количества памяти) будут происходит эти операции перекачки данных из памяти на диск и обратно.
Таким образом в архитектуре выделенного сервера, производительность может падать если ваша операционная система не поддерживает большого количества одновременно работающих процессов и проблемы могут усугубляться при отсутствии достаточного количества памяти. Надо отметить что на самом деле не важна активность подключенных сессий. Даже для неактивных сессий процесс создан и операционная система будет переключаться на эти процессы и перекачивать данные при необходимости согласно алгоиртму разделения времени. И тогда наступает момент что как бы вы не улучшали аппаратные средства, производительность начинает падать из-за неэффективности операционной системы при управлении операциями context switch и памятью. Для преодоления этих ограничений Oracle предлагает использовать архитектуру общего сервера (shared server architecture). Это позволяет обслуживать большое количество пользовательских процессов относительно небольшим количеством серверных процессов, и таким образом уменьшается количество процессов для управления операционной системой. Как дополнительный плюс уменьшается количество используемой памяти.
Надо помнить что потребность в архитектуре общего сервера очень сильно зависит от используемой платформы. Некоторые ОС не нуждаются в этом.
Архитектура общего сервера
Сразу необходимо отметстьи что архитектура общего сервера полностью реализуется на стороне сервера. Пользовательские процессы и программы не ощущают разницы при работе. Пользовательский процесс преобразует строку подключения в сетевой адрес listener-а и имя сервиса (или экземпляра) и посылает запрос к listener-у на подключение. Результатом подключения будет сетевой процесс. Этот процесс будет использоваться для отправки SQL запросов и получения результатов. Т.е. со стороны пользовательского процесса ничего не изменилось, всё так же как и в случае с выделенным сервером. Но серверная часть существенно отличается.
Архитектура общего сервера реализуется путём введения дополнительных процессов как части экземпляра БД. Это фоновые процесса запускаемые в момент запуска экземпляра. Эти процессы разделяют на два типа: диспетчеры и общие серверные процессы (dispatchers и shared servers process). Так же создаются дополнительные структуры памяти (очереди) в SGA и listener начинает работать немного по другому. Когда экземпляр БД настроен для запуска как общий сервер, в дополнение к обычным фоновым процессам запускается один или несколько процессов диспетчеров. Диспетчеры, так же как любые другие фоновые процессы, работают на определённом порту выделенном ОС: они могут взаимодействовать с listener-ом и регистрироваться, используя параметр БД local_listener для обнаружения настроенных listener-ов. Также запускается один или несколько общих серверных процессов (shared server process). Концептуально они ничем не отличаются в работе от обычных выделенных серверных процессов, но главное отличие это то что они не привязываются к одной конкретной сессии. Они получают SQL запросы, разбирают их и возвращают результат выполнения – но они не получают SQL запросы напрямую от пользовательских процессов. Эти процессы считывают их из очереди, которая формируется из запросов от любого количества пользовательских процессов. Подобным образом серверные процессы не возвращают результаты выполнения напрямую пользовательскому процессу – вместо этого, они кладут результат выполнения в очередь ответов. Возникает вопрос, как пользовательские запросы попадают в очередь для считывания серверным процессом и как результаты возвращаются пользователям? За это и ответственен диспетчер. Когда пользовательский процесс посылает запрос listener-у, вместо того чтобы создать серверный процесс и вернуть его адрес пользовательскому процессу, listener возвращает адрес диспетчера. Если создан только один диспетчер – listener подключит все входящие запросы к этому диспетчеру. Если созданы несколько диспетчеров – listener будет распределять входящие запросы на подключением между ними. Каждый пользовательский процесс думает что он взаимодействует с выделенным процессом, но это не так: диспетчер работает со многими пользовательскими процессами. Со стороны сети взаимодействие многих пользовательских процессов будет осуществляться по одному порту используемому диспетчером.
Когда пользователь запускает SQL запрос на выполнение он отсылается к диспетчеру. Диспетчер помещает все запросы в очерель. Эта очередь называется общей очерелью (common queue) так как её используют все диспетчеры. Вне зависимости к какому диспетчеру подключен пользовательский процесс все запросы помещаютяс в общую очередь. Все общие серверные процессы просматривают эту очередь. Когда запрос помещается в очередь – первый доступный серверный процесс забирает запрос. С точки зрения выполнения запроса происходит обычный цикл разбора-привязки-выполнения, но когда наступает этап выборки данных – серверный процесс не может отправить результат обратно пользовательскому процессу – между ними нет соединения. Вместо этого общий серверный процесс помещает результат выполнения в очередь ответов (response queue) которая принадлежит тому диспетчеру который получил этот запрос от пользовательского процесса. Каждый диспетчер просматривает свою очередь ответов, и когда результат готов, диспетчер заберёт его из очереди и отправит соответствующему пользовательскому процессу. На картинке 4-11 показано как три пользовательских процесса работают в архитектуре общего сервера. Пользовательские процессы 1 и 2 подключаются к экземпляру и назначаются диспетчеру 1, а пользовательский процесс 3 соединяется с диспетчером 2.
Результатом механизма диспетчеров и очередей является то что любой запрос любого пользовательского процесса может быть выполнен первым доступны общий серверным процессом. Всплывает вопрос как управляется состояние сессий. Пользовательский процесс вполне вероятно может выполнить команду SELECT FOR UPDATE, DELETE и COMMIT. В архитектуре выделенного сервера это не вызывает проблем, так как PGA ( привязанная именно к этой сессии) хранит информацию об активности сессии, и сервер знает какие изменения сохранить и какие блоки памяти разблокировать. PGA для сессии в архитектуре выделенного сервера хранит информацию о самой сессии, состояние курсоров, место для сортировки и состояние стека. В архитектуре общего сервера каждый запрос может выбираться из общей очереди разными серверными процессами, которые понятия не имеют о состоянии транзакции. Для преодоления этой проблемы, общие серверные процессы хранят информацию о сессиях в SGA вместо PGA. Таким образом когда бы серверный процесс не выбрал запрос на выполнение из общей очереди, этот процесс обратиться к соответствующем блоку в SGA и получит информацию о состоянии сессии. Область памяти в SGA используемая общими серверными сессиями называется общая пользовательская область (UGA user global area) и включает в себя всё что хранилось в PGA за исключением состояния стека. Вот откуда появляется экономия памяти. Oracle может управлять памятью в shared pool-е гораздо эффективнее чем во многих отдельных PGA. Часть SGA используемая для UGA – это large pool.
Настройка общего сервера
Так как архитектура общего сервера является особенностью только сервера, с клиентской стороны не нужна дополнительная настройка кроме создания файлов для Oracle Net (sqlnet.ora и tnsnames.ora). Со стороны сервера настройка требуется только для экземпляра БД. Listener автоматически подхватит конфигурацию shared server с помощью динамической регистрации. Таким образом shared server настраивается путём выставления соответствующих значений параметров инициализации экземпляра. Доступны несколько различных параметров, но два необходимых это: dispatchers и shared_servers.
Рассмотрим параметр shared_service. Этот параметр контролирует количество общих серверных процессов которые будут запущены в момент запуска экземпляра. Общие серверные процессы используют механизм очереди, но в идеальном случае очередь должна быть пустой: всегда должен быть доступен процесс для выполнения работы, которая появляется в общей очереди. То есть значение shared_servers должно быть установлено таким образом, чтобы быть равным предполагаемому количеству запросов выполняемых одновременно. Но если возникнет всплеск активности, Oracle динамически создат ещё процессы, количество которых ограничего значением параметра max_shared_servers. По умолчанию значение shared_servers равно единице если установлено значение переменной dispatchers. Если параметр max_shared_servers не установлено то используется значение по умолчанию равное одной восьмой от параметра processes.
Параметр dispatchers контролирует сколько диспетчеров запускать во время старта экземпляра и определяет их поведение. Это единственный обязательный параметр. Доступно много дополнительных опций, но две самые важные это: сколько процессов запускать и какой протокол использовать. Среди других опций доступны такие, которые позволяют устанавливать сетевой интерфейс и порт для диспетчеров, настраивать адреса listener-ов для регистрации и т.п. Параметр max_dispacthers устанавливает верхнюю границу количества допустимых для запуска диспетчеров, но этот параметр работает не так как max_shared_server. Oracle не будет сам автоматически запускать дополнительные процессы, но вы можете запустить вручную ещё процессы максимальным количеством не превышающим значение параметра max_dispatchers.
Рассмотрим пример настройки архитектуры общего сервера. Для этого достаточно выполнить команды
alter system set dispatchers=’(dispatchers=2)(protocol=tcp’;
alter system set shared_servers=20;
Настройка общего сервера очень важна. Всегда должно быть доступно достаточно общих серверных процессов для обработки запросов из общей очереди по мере их поступления и достаточно диспетчеров для обсуживания входящих запросов и возврата результатов обработанных запросов. При использовании архитектуры общего сервера необходимо контролировать потребление памяти общими серверными процессами в SGA. При переходе от выделенного сервера к общему размер SGA необходимо существенно увеличить.
14
Configuring Shared Server
This chapter describes how to configure shared server. It contains these topics:
Configuring Shared Server with the DISPATCHERS Parameter
To enable a shared server configuration, set the DISPATCHERS parameter in the database initialization parameter file.
After setting this parameter, restart the instance to enable shared server configuration. Set DISPATCHERS as follows:
One of the following attributes is required to enable shared server:
Table 14-1 Required Attributes of the DISPATCHERS Parameter
ADDRESS ( ADD or ADDR )
Specify the network protocol address of the endpoint on which the dispatchers listen.
DESCRIPTION ( DES or DESC )
Specify the network description of the endpoint on which the dispatchers listen, including the network protocol address. The syntax is as follows:
PROTOCOL (PRO or PROT)
Specify the network protocol for which the dispatcher generates a listening endpoint. For example:
See Also: Oracle9i Net Services Reference Guide for further information about protocol address syntax
The following attributes are optional:
Table 14-2 Optional Attributes of the DISPATCHERS Parameter
CONNECTIONS ( CON or CONN )
Specify the maximum number of network connections to allow for each dispatcher.
The default is operating system specific. For example, 1024 is the default for Solaris Operating System and Windows NT.
DISPATCHERS ( DIS or DISP )
LISTENER ( LIS or LIST )
Specify an alias name for the listeners with which the PMON process registers dispatcher information. Set the alias to a name which is resolved through a naming method.
The LISTENER attribute overrides the LOCAL_LISTENER and REMOTE_LISTENER initialization parameters. The LISTENER attribute only needs to be specified if its value is different from the values specified by the LOCAL_LISTENER and REMOTE_LISTENER parameters. Note that the LOCAL_LISTENER parameter has a default value of TCP/IP, port 1521.
See Also: «Configuring Service Registration» for further information about the LOCAL_LISTENER and REMOTE_LISTENER parameters
Important: Resolve the listener alias through a naming method, such as a tnsnames.ora file on the database server or an Oracle Names server.
For example, if the listener alias name is listener_sales with two listening endpoints of port 1521, and the chosen naming method is the local naming method, the entry in the tnsnames.ora file would look like the following:
MULTIPLEX ( MUL or MULT )
Use to enable the Oracle Connection Manager session multiplexing feature.
If IN is specified, then session multiplexing is enabled for incoming network sessions from clients.
If OUT is specified, then session multiplexing is enabled for outgoing network sessions.
If a number is specified, enables connection pooling for both incoming and outgoing idle network connections. The number specified is the timeout in ticks for both incoming and outgoing idle network connections.
If OUT is specified, connection pooling is enabled for outgoing idle network connections and the default timeout of 10 ticks is used for outgoing network connections. OUT can also be assigned a timeout in ticks value, such as ( OUT=20 ). If the numeric value of a specified timeout is 0 or 1, then the default value of 10 ticks is used.
SERVICE ( SER or SERV )
Specify the service names the dispatchers register with the listeners. If no values are specified, then service names specified with the SERVICE_NAMES initialization parameter are used.
SESSIONS ( SES or SESS )
Specify the maximum number of network sessions to allow for each dispatcher.
The default is operating system specific. Most operating systems have a default of 16 KB.
TICKS ( TIC or TICK )
Specify the length of a network tick in seconds. A tick is the amount of time it takes for a message to be sent and processed from the client to the database server or from the database server to the client. The value set is multiplied with the POOL timeout value to get the total connection pool timeout.
The default is 1 second. For a fast network, Oracle Corporation recommends a tick size of
1 second. For a slow network, Oracle Corporation recommends a tick size of
Setting the Initial Number of Dispatchers
The number of dispatchers started at instance startup is controlled by the DISPATCHERS attribute.
The appropriate number of dispatchers for each instance depends upon the performance you want from your database, the host operating system limit on the number of connections for each process, which is operating system dependent, and the number of connections required for each network protocol.
Calculating the Initial Number of Dispatchers
Once you know the number of possible connections for each process for the operating system, calculate the initial number of dispatchers to create during instance startup, for each network protocol, using the following formula.
CEIL represents the number roundest to the next highest whole integer.
Example: Initial Number of Dispatchers
Assume a system that has:
In this case, the DISPATCHERS attribute for TCP/IP should be set to a minimum of four dispatchers and TCP/IP with SSL should be set to a minimum of three dispatchers:
Depending on performance, you may need to adjust the number of dispatchers.
Example: Dispatcher Address with IP Address
To force the IP address used for the dispatchers, set the following:
This starts two dispatchers that listen on host 144.25.16.201. Note that Oracle Net dynamically selects the TCP/IP port for the dispatcher.
Example: Dispatcher Address with PORT
To force the exact location of the dispatchers, add the PORT as follows:
You can specify multiple DISPATCHERS in the initialization file, but they must be adjacent to each other.
Enabling Connection Pooling
Connection pooling is a resource utilization feature that enables you to reduce the number of physical network connections to a dispatcher. This is achieved by sharing or pooling a set of connections among the client processes.
To configure connection pooling, set the DISPATCHERS parameter in the initialization parameter file with the POOL attribute and the following optional attributes:
Allocating Resources
An Oracle database can be represented by multiple service names. Because of this, a pool of dispatchers can be allocated exclusively for clients requesting a particular service. This way, the mission critical requests may be given more resources and, thus, in effect increase their priority.
Using Shared Server on Clients
If shared server is configured and a client connection request arrives when no dispatchers are registered, the requests can be handled by a dedicated server process (configured in the listener.ora file). If you want a particular client always to use a dispatcher, configure (server=shared) in the connect data portion of the connect descriptor. For example:
If a dispatcher is not available, the client connection request is rejected.
Overriding Shared Server on Clients
If the database is configured for shared server and a particular client requires a dedicated server, you can configure the client to use a dedicated server in one of the following ways: