Организация пула постоянных соединений базы данных

В традиционной архитектуре клиент/сервер существует соответствие один к одному между пользовательской сессией и соединением базы данных. Однако в системе, основанной на Web, это может быть не так.

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

Установления соединения достаточно дорого по своим накладным расходам, поэтому кэширование соединений является важным требованием в таких приложениях. В этой модели, когда странице необходимо соединение с базой данных, из пула выталкивается одно из уже установленных соединений. После того как работа сделана, Web сессия возвращает соединение обратно в пул.

Однако существуют проблемы с традиционной клиент/серверной организацией или организацией пула на среднем уровне:

Ограничение каждого пула одним узлом среднего уровня.
Непомерное разрастание результатов пула в заранее размещенных серверах базы данных и чрезмерное расходование памяти сервера базы данных.
Рабочая нагрузка распределена неравномерно между пулами.

Чтобы избежать этой проблемы база данных Oracle 11g предоставляет пул, расположенный на сервере, который называется пул постоянных соединений базы данных (Database Resident Connection Pool - DRCP).Этот пул доступен всем клиентам, которые используют OCI драйвера, включая C, C++, и PHP.

По умолчанию база данных Oracle 11g поставляется с уже установленным пулом соединений, но он отключен. Чтобы запустить его, нужно выполнить:

execute dbms_connection_pool.start_pool;

Теперь, чтобы вместо обычной сессии использовать соединения, хранящиеся в пуле, всё, что необходимо сделать, это добавить строку (SERVER=POOLED) в содержимое TNS, как показано ниже:

PRONE3_POOL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = prolin3.proligence.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = POOLED) (SID = PRONE3) ) )

Теперь клиенты могут подключаться к пулу соединений (connection pool), используя строку соединения PRONE3_POOL. Приложения будут взимодействовать с пулом, а не с сервером. Если используется стандартная строка соединения из файла TNSNAMES.ORA, следует применить фразу POOLED. К примеру в PHP, это выглядит так:

$c = oci_pconnect(‘myuser’,‘mypassword’,’prolin3.proligence.com/PRONE3:POOLED’);

или

$c = oci_pconnect(‘myuser’, ‘mypassword’,’PRONE3_POOLED’);

В вышеприведенном описании мы запускали пул по умолчанию, который поставляется с Oracle с опцией по умолчанию. Можно использовать процедуру CONFIGURE_POOL в стандартном пакете DBMS_CONNECTION_POOL:

Параметр

Описание

POOL_NAME	Имя пула. Используйте ‘’ (две одинарных кавычки для пула по умолчанию)
MINSIZE	Минимальное количество сессий, хранящихся в пуле
MAXSIZE	Максимальное количество сессий, хранящихся в пуле
INCRSIZE	Когда опрашиваемый сервер недоступен, пул создает заданное количество новых соединений
SESSION_CACHED_CURSORS	Включает кэширование курсоров сессии
INACTIVITY_TIMEOUT	Если сессия не используется в течение этого времени, то она отсоединяется
MAX_THINK_TIME	После того как клиент получил соединение из пула, он должен выполнить SQL оператор в течение этого времени, иначе клиент потеряет соединение
MAX_USE_SESSION	Максимальное количество раз, которое соединение может быть взято и помещено обратно в пул
MAX_LIFETIME_SESSIONE	Как долго сессия должна существовать

Функциональность DRCP очень важна, поскольку один пул может поддерживать десятки тысяч одновременно работающих пользователей на выгодной основе. Более того, один пул может разделяться между многими клиентами или узлами среднего уровня, и в конфигурации RAC и Data Guard комбинация DRCP и событий FAN предоставляют возможность быстрого преодоления отказа соединений.

Arup Nanda (arup@proligence.com) has been exclusively an Oracle DBA for more than 12 years with experiences spanning all areas of Oracle Database technology, and was named "DBA of the Year" by Oracle Magazine in 2003. Arup is a frequent speaker and writer in Oracle-related events and journals and an Oracle ACE Director. He co-authored four books, including RMAN Recipes for Oracle Database 11g: A Problem Solution Approach.

Содержание раздела