О, а вот это новая вводная в Вашей истории. И это много чего меняет, ведь мы именно обсуждаем проблему коннекта при достижении некоего лимита. Т.е. способ коннекта, SHARED/DEDICATED - как раз предмет расследования.
Полагаю, у Вас были достаточные основания для использования MTS, тем более на Windows. Вы же знаете, MTS не самая, скажем так, популярная технология, хотя безусловно имеет право на использование. Просто опыта с ней на порядки меньше, плюс часто в интернете, даже тот же Т.Кайт говорит - используйте, только если ну очень надо. И 6000 сессий - не такое уж большое значение, если бы 60 000 сессий, или 6000 коннектов в секунду - тогда да, тут уж надо думать, что с ними делать.
В общем, MTS привносит свои изменения в привычный "уклад" работы Oracle, и как устанавливаются соединения с базой, и как используется память. Т.к. в случае MTS, UGA выделяется из Large Pool (вместо PGA), а если там уже не хватает - то из Shared Pool - поэтому убедитесь, что Large Pool и Shared Pool достаточно большие для Ваших нескольких тысяч сессий, осмотрите все mts_* параметры - как те что выставлены вручную в INIT.ORA, так и остальные, рассчитанные на их основе значения:
1.
2.
3.
4.
5.
6.
7.
shared_servers
max_shared_servers
dispatchers
max_dispatchers
circuits
shared_server_sessions
local_listener
Посмотреть текущие настройки диспетчеров MTS и прочие сопутствующие настройки можно во view (желательно под максимальной нагрузкой, чтобы видеть значения установленных сессий и их распределение по диспетчерам):
1.
2.
3.
v$dispatcher_config
v$dispatcher
v$shared_server
Посмотреть количество установленных соединений через MTS диспетчеры можно ещё через вывод lsnrctl services. В смысле - кроме классического поля V$SESSION.SERVER.
В настройках диспетчеров есть свои лимиты SESSIONS и CONNECTIONS. Если они не указаны вручную - то какие именно default-значения они принимают, тем более под Windows - надо смотреть, нет под рукой площадки проверить.
И кстати, для тестов, чтоб не менять настройки базы и не перезагружать её - можно на стороне клиента, если у Вас (вдруг) все коннекты идут из одного места (от одного сервера приложений) - можно в одном месте на время тестов изменить tnsnames.ora файл и добавить SERVER=DEDICATED, таким образом заставить все сессии соединяться в обход MTS, в "обычном" (DEDICATED а не SHARED) режиме. Таким образом можно на день потестировать, проблема в MTS или нет.
Или, чтобы не править конкретный TNS-Alias, можно централизованно добавить в sqlnet.ora строчку:
Тогда для всех записей (алиасов) в tnsnames.ora, автоматически будет подставляться настройка SERVER=DEDICATED, тут как Вам удобней.
Но еще раз, это удобно и быстро и просто потестировать, если у Вас классическое 3-Tier приложение, и все коннекты в базу идут от одного сервера (или нескольких), и поменять на время тестов tnsnames.ora / sqlnet.ora быстро и не накладно. Если все Ваши 6000+ коннектов идут с 6000+ хостов (компов), и tnsnames.ora / sqlnet.ora у всех свой, локальный, а не общий на shared-диске - то это нереально конечно. Хотя, опять же, всякие варианты с централизованным deployment файлов tnsnames.ora / sqlnet.ora тоже могут быть в организации. Тут уж Вам видней.
