Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

ORA-00018 1С:Предприятие и СУБД

Ошибка ORA-00018: maximum number of sessions exceeded в Oracle Database

Обновлено: 26.08.2026 · Официальная документация ↗
  • Клиенты и пулы соединений получают ошибку ORA-00018: maximum number of sessions exceeded при попытке подключения.
  • Администратор не может войти под обычной учетной записью (вход возможен только через sqlplus / as sysdba локально через операционную систему).
  • В alert.log регистрируются предупреждения о достижении системного лимита сессий.

1. Диагностика текущего количества сессий и лимитов

Подключитесь через SYSDBA на сервере СУБД:

sqlplus / as sysdba

Выполните запрос к представлению v$resource_limit:

SELECT resource_name, current_utilization, max_utilization, initial_allocation, limit_value
FROM v$resource_limit
WHERE resource_name IN ('sessions', 'processes');

2. Анализ распределения сессий по пользователям и программам

SELECT username, program, machine, status, COUNT(*)
FROM v$session
GROUP BY username, program, machine, status
ORDER BY COUNT(*) DESC;

3. Увеличение лимита сессий в SPFILE

Формула по умолчанию в Oracle: sessions = (1.5 * processes) + 22. Для изменения параметров выполните:

ALTER SYSTEM SET processes=1000 SCOPE=SPFILE;
ALTER SYSTEM SET sessions=1522 SCOPE=SPFILE;

Примечание: Изменение параметров processes и sessions требует перезапуска экземпляра базы данных (SHUTDOWN IMMEDIATE / STARTUP).

4. Принудительное завершение зависших неактивных сессий

SELECT 'ALTER SYSTEM KILL SESSION ''' || sid || ',' || serial# || ''' IMMEDIATE;' 
FROM v$session 
WHERE status = 'INACTIVE' AND last_call_et > 7200;
💡 Практика специалистов: Если ошибка возникает внезапно, проверьте пулы соединений приложений (Connection Leaks). Незакрытые соединения в коде (connection leak) исчерпают любой лимит, сколько бы вы его ни поднимали в SPFILE.

Частые вопросы (FAQ)

Почему ORA-00018 блокирует подключение даже при наличии свободной памяти на сервере?

Лимит сессий является жестко зафиксированным статическим параметром в управляющих структурах SGA. Даже если сервер имеет терабайты свободной RAM, Oracle не выделит дескриптор новой сессии сверх лимита sessions.

Как настроить автоматическое отключение зависших неактивных сессий?

Используйте профили пользователей (Profiles): настройте параметр IDLE_TIME (например, ALTER PROFILE app_profile LIMIT IDLE_TIME 60;) и включите resource_limit (ALTER SYSTEM SET resource_limit=TRUE SCOPE=BOTH;).

Как подключиться к базе, если лимит полностью исчерпан?

Подключение через 'sqlplus / as sysdba' на локальном хосте резервирует специальный системный слот и работает даже при исчерпании лимита sessions.

Связаны ли между собой параметры processes и sessions?

Да, при выделенном сервере (Dedicated Server) каждому процессу операционной системы соответствует как минимум одна сессия. В shared server конфигурации одна сессия может разделяться между пулами.

Полезные материалы
Рекомендуем