Отношение между сессией Oracle и пулом соединения

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

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

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

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

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

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

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

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

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

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

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

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

SQL> show parameter processes

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

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

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

Metalink дает следующие советы по параметру SESSIONS:

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

Решение:

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

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

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