Связь между сессией Oracle и пулом соединений

Question

Позвольте мне сначала объяснить настройки.

У нас есть сервер Oracle, работающий на машине с 2 ГБ ОЗУ. Экземпляр Db имеет параметр init "session", установленный на 160.

У нас есть приложение, развернутое на Websphere 6.1. Настройки пула подключений - от 50 до 150.

Когда мы запускаем нагрузочное тестирование для 40 пользователей (одновременно с использованием jMeter), все идет хорошо. Но когда мы увеличиваем количество одновременных пользователей до уровня свыше 60, Oracle выдает и исключает, что он вне сеансов.

Мы проверили приложение на наличие утечек соединения, но не смогли найти.

Так значит ли это, что параллелизм 40 - это то, что может взять эта установка? Является ли увеличение числа сеансов / процессов Oracle единственным способом получения более высокого уровня параллелизма?

Как связаны между собой сеансы БД и соединение в пуле соединений? Насколько я понимаю, количество подключений не может превышать количество сеансов, поэтому настройка максимального количества подключений в пуле не может иметь большого значения. Это правильно?

Answer 1

Проверьте эту книгу в Google Книгах. Это объясняет различия между соединениями и сессиями.

Answer 2

Металинк дает следующий совет по параметру SESSIONS:

Рекурсивные сеансы являются неотъемлемой частью нормального функционирования RDBMS. Невозможно идентифицировать каждое обстоятельство, которое потребует такие сессии, но в целом, если инициированная пользователем операция требует манипулирование словарем данных объекты, то рекурсивные сеансы могут создать. Чтобы взять простой пример, скажем, вы создали таблицу во время входа в систему как обычный пользователь. За сцены это должно вставить строки в obj $, tab $ и т. д., которые принадлежат Пользователь SYS. Так как обычный пользователь будет не имеют права вставлять в них объекты, рекурсивный сеанс создал который входит в систему как SYS.

Решение:

Увеличить параметр SESSIONS.

Рекомендация - сохранить 50% значение SESSIONS для рекурсивного сессий. Так, например, если это ожидается 30 сеансов клиентов открыть, затем установить параметр SESSIONS до 60.

Итак, в зависимости от того, что делают websphere и ваш пользовательский процесс, это может частично объяснить то, что вы видите.

Answer 3

My v $ session содержит 30 записей, 4 из которых имеют имя пользователя (одна из которых является фоновым заданием).

Если у вас есть фоновые процессы (например, пакетные задания), они могут жевать сессии.

Но может быть, вам просто не хватает памяти. 2 ГБ кажется немного низким для пула подключений из 50 сеансов. Предполагая, что Oracle 10g, ваша оперативная память делится на разделяемую (SGA) и процессную (PGA). Допустим, у вас есть 1,5 ГБ для SGA, что оставляет 500 МБ на все сессии. Если каждая сессия занимает 10 МБ, вы достигнете лимита в 50 сессий.

На самом деле, 1. У вас будут другие «вещи», работающие на коробке, поэтому у Oracle не будет полных 2 ГБ, доступных

2. Ваш SGA может быть меньше или больше
3. Возможно, вы используете 11g и позволяете Oracle распределять PGA и SGA из одного пула
4. Возможно, вы используете PGA_AGGREGATE_TARGET (позволяя Oracle угадывать настройки PGA на основе количества сеансов) или устанавливаете ограничения памяти самостоятельно.
5. У вас могут быть некоторые процессы, требующие памяти, которые жуют вещи

PS. 2 ГБ означают, что вы используете Windows?

Answer 4

Пул сеансов управляется на стороне клиента. Он не знает (или не контролирует), сколько сеансов позволит база данных.

Вы должны посмотреть на сервере, чтобы определить фактическое число разрешенных соединений и установить номер пула сеансов в зависимости от того, что разрешит сервер.

Ваш пул соединений не должен использовать все разрешенные соединения. Это позволит другим идентификаторам соединиться. Если у вас есть приложение, использующее USER_1, вы должны настроить пул соединений на использование некоторого количества разрешенных соединений, но оставить достаточно соединений для ... О, скажем, администратор БД для входа в систему.

- Правка -
Вероятно, процессы заканчиваются до того, как ваш пул соединений исчерпает себя.

SQL> show parameter processes

NAME                                 TYPE        VALUE
--------------------------------------------------------------------------------
processes                            integer     40

Это общее количество разрешенных процессов. Теперь посмотрим, сколько из них уже используется - многие из них являются фоновыми процессами, о которых вы никогда не подумаете.

SQL> select count(*) from v$process;

Answer 5

Все ли ваши подключения используют одну и ту же учетную запись пользователя? Если это так, вы можете проверить, есть ли у вас ограничение на количество сеансов для этой учетной записи.

Кроме того, у вас есть лицензия на более чем 40 подключений? (Проверьте, установлен ли в вашем файле параметров LICENSE_MAX_SESSION)