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

Ошибка ORA-04031: unable to allocate shared memory — настройка Shared Pool

Обновлено: 26.08.2026 · Официальная документация ↗

Запросы падают с ошибкой ORA-04031: unable to allocate N bytes of shared memory ("shared pool", ... , "SQLA^...", "kglsim heap").
Высокая конкуренция за библиотечный кэш (Library Cache Latch Contention / Mutex Sleep).
Производительность базы данных резко падает из-за постоянных жестких разборов (Hard Parse).

1. Анализ свободного места в пулах SGA

SELECT pool, name, bytes/1024/1024 AS mb 
FROM v$sgastat 
WHERE pool = 'shared pool' AND (name LIKE '%free memory%' OR bytes > 50*1024*1024)
ORDER BY bytes DESC;

2. Увеличение размера SGA и Shared Pool

ALTER SYSTEM SET sga_target = 32G SCOPE=BOTH;
ALTER SYSTEM SET shared_pool_size = 8G SCOPE=BOTH;

3. Включение CURSOR_SHARING для борьбы с литералами

Если приложение генерирует тысячи непараметризованных SQL-запросов с константами вместо Bind Variables:

ALTER SYSTEM SET cursor_sharing = FORCE SCOPE=BOTH;

4. Временная очистка Shared Pool без перезагрузки БД

ALTER SYSTEM FLUSH SHARED_POOL;

5. Фиксация (Pinning) критических пакетов в памяти

EXECUTE DBMS_SHARED_POOL.KEEP('SYS.STANDARD');
EXECUTE DBMS_SHARED_POOL.KEEP('SYS.DBMS_SQL');

💡 Практика специалистов: Для СУБД под 1С:Предприятие обязательно резервируйте _shared_pool_reserved_min_alloc и не уменьшайте параметр shared_pool_size ниже 4–8 GB при больших объемах конфигурации.

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

Почему ORA-04031 возникает при наличии свободного места (free memory) в Shared Pool?

Причиной является сильная фрагментация памяти: свободный объем разделен на миллионы микроскопических фрагментов, и Oracle не может найти ни одного непрерывного чанка требуемого размера.

Что вызывает жесткие разборы (Hard Parses)?

Выполнение динамических запросов без переменных связывания (Bind Variables). Каждый уникальный текст запроса генерирует новый курсор и план выполнения в Library Cache.

Опасно ли выполнять ALTER SYSTEM FLUSH SHARED_POOL на проде?

Команда сбрасывает кэшированные планы. Это вызывает мгновенный всплеск нагрузки на CPU из-за повторного компилирования всех поступающих запросов, но помогает как экстренная мера.

Как автоматическое управление памятью (ASMM) реагирует на ORA-04031?

ASMM динамически перераспределяет память между Buffer Cache и Shared Pool, однако при резких всплесках фрагментации фоновый процесс MMAN может не успеть выполнить ресайз.