Ora 04031 невозможно выделить байт разделяемой памяти
Когда я работал над проектом сегодня, потому что я изменил IP-адрес удаленного доступа, я продолжал сообщать о следующих ошибках:
Baidu не работает Были найдены следующие решения:
1.ORACLE BUG
Oracle рекомендует последний пакет исправлений для вашей системы. Большинство ошибок ORA-04031 связано с ошибками, и их можно избежать с помощью этих исправлений.
В следующей таблице приведены наиболее распространенные ошибки, возможные среды и исправления, которые устраняют эту проблему.
Ошибка Описание Обходной путь Исправлен
ORA-4031/SGA memory leak of PERMANENT memory occurs for buffer handles _db_handles_cached = 0 901/ 8172
ORA-4031 due to leak / cache buffer chain contention from AND-EQUAL access Not available 8171/901
INSERT AS SELECT statements may
not be shared when they should be
if TIMED_STATISTICS. It can lead to ORA-4031 _SQLEXEC_PROGRESSION_COST=0
8171/8200
Cursors may not be shared in 8.1
when they should be Not available 8162/8170/ 901
ORA-4031/excessive "miscellaneous" shared pool usage possible. (many PINS) None-> This is known to affect the XML parser. 8174, 9013, 9201
Several number of BUGs related to ORA-4031 erros were fixed in the 9.2.0.5 patchset Not available 9205
ORA-4031, который появляется при компиляции кода Java
Если вам не хватает памяти при компиляции кода Java, вы увидите ошибку:
Небольшой общий размер пула
Во многих случаях слишком маленький общий пул может вызвать ошибку ORA-04031. Следующая информация поможет вам настроить размер общего пула:
Частота попаданий в кэш библиотеки
Частота обращений помогает вам измерить использование общих пулов и определить, сколько операторов нужно анализировать, а не использовать повторно. Следующий оператор SQL поможет вам рассчитать частоту обращений к кешу библиотеки:
SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;
Если потеря превышает 1%, попробуйте уменьшить потерю кэша библиотеки, увеличив размер общего пула.
Расчет размера общего пула
Чтобы рассчитать размер общего пула, который лучше всего подходит для вашей рабочей нагрузки, обратитесь к:
: HOW TO CALCULATE YOUR SHARED POOL SIZE.
Фрагментация общего пула
Каждый раз анализируемая форма оператора SQL или PL / SQL, который необходимо выполнить, загружает определенный непрерывный пробел в общий пул. Первый ресурс, который будет проверен базой данных, - это свободная доступная память в общем пуле. Как только свободная память исчерпана, база данных должна найти часть памяти, которая была выделена, но еще не использована для повторного использования. Если такой большой блок точного размера недоступен, продолжайте поиск по следующим критериям:
Размер чанка больше, чем запрашиваемый размер
Пространство непрерывно
Большие блоки памяти доступны (вместо того, чтобы использоваться)
Таким образом, большие блоки памяти разделяются, а остальное добавляется в соответствующий список свободного места. Когда база данных работает таким образом в течение определенного периода времени, в структуре общего пула происходит фрагментация.
Когда существует проблема фрагментации в общем пуле, потребуется больше времени для выделения свободного пространства, и производительность базы данных также снизится (в течение всей операции «выделение чанков» контролируется защелкой, называемой «защелкой общего пула») Или это ошибки ORA-04031 (когда база данных не может найти непрерывный блок свободной памяти).
См. : вы можете получить подробное обсуждение фрагментации общего пула.
Если SHARED_POOL_SIZE достаточно велик, большинство ошибок ORA-04031 вызвано динамической фрагментацией SQL в общем пуле. Возможные причины следующие:
Неподеленный SQL
Генерация ненужных вызовов синтаксического анализа (мягкий анализ)
Переменная связывания не используется
Чтобы уменьшить образование мусора, необходимо определить возможные факторы, описанные выше. Конечно, вы можете использовать следующие методы, не ограничиваясь этими типами: настройка приложения, настройка базы данных или настройка параметров экземпляра.
Пожалуйста, обратитесь к , где описаны все эти детали. В этом примечании также содержатся сведения о том, как работает общий пул.
Следующее представление помогает пометить неиспользуемый SQL / PLSQL в общем пуле:
V $ SQLAREA view
Это представление содержит информацию о операторах SQL и блоках PL / SQL, выполняемых в базе данных. Следующие операторы SQL могут показывать операторы с литералом или операторы со связанными переменными:
SELECT SUBSTR (sql_text, 1, 40) "SQL", COUNT (*),
SUM (executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY SUBSTR (sql_text, 1, 40)
HAVING COUNT (*) > 30
ORDER BY 2;
Примечание: значение после «30» можно отрегулировать по мере необходимости, чтобы получить более подробную информацию.
X $ KSMLRU view
Эта фиксированная таблица x $ ksmlru отслеживает приложения в общем пуле, которые вызывают старение других объектов. Эта фиксированная таблица может быть использована для обозначения того, что привело к большим приложениям.
Если многие объекты периодически обновляются в общем пуле, это может вызвать проблемы со временем отклика и проблемы с защелкой кэша библиотеки при перезагрузке объектов в общий пул.
Необычная вещь в этой таблице x $ ksmlru состоит в том, что, если кто-то выбирает содержимое из таблицы, содержимое этой таблицы будет удалено. В этой фиксированной таблице хранится только самое большое распределение, которое когда-либо происходило. Это значение сбрасывается после выбора, чтобы можно было пометить следующее большое распределение, даже если они не такие большие, как предыдущее распределение. Из-за этого сброса результаты после отправки запроса не могут быть получены снова, и выходные данные из таблицы должны быть тщательно сохранены. Следите за этой фиксированной таблицей и выполните следующие операции:
SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;
Эта таблица может быть запрошена только при входе пользователя в систему SYS.
Представление X $ KSMSP (аналогично информации Heapdump кучи)
Используя это представление, можно узнать выделенное в настоящее время свободное пространство, что помогает понять степень фрагментации общего пула. Как мы описывали ранее, первое место, где нужно найти достаточно большой объем памяти, выделенный для курсора, - это свободный список. Следующее утверждение показывает большой блок памяти в свободном списке:
Единственный установленный параметр, связанный с памятью: MEMORY_TARGET = 1.2G
Oracle 11.2 x64 Standard Edition One Windows Server 2008 R2
Ваше приложение, вероятно, не использует переменные связывания, из-за чего SGA становится фрагментированным (оно заполняется несколькими копиями SQL, которые используют литералы вместо связывания).
Вы можете временно устранить проблему, сбросив общий пул с помощью:
Есть обходной путь, который вы можете попытаться остановить в будущем.
Включите совместное использование курсора, затем сбросьте базу данных:
Как я уже сказал, если причиной проблемы является приложение, не использующее переменные связывания, единственный способ «решить» это переписать приложение, чтобы использовать их.
Я попробую оба решения, если проблема возникнет снова. Но я не думаю, что это применимо к этому случаю, потому что это происходит, даже если это первый запрос после перезапуска.
Ответ выше немного стар.
Может решить проблему сразу, но не устранит первопричину. Параметр cursor_sharing теперь принимает 2 значения:
СИЛА или ТОЧНОСТЬ. С EXACT ваш запрос должен точно совпадать с курсором (sql с планом выполнения) для повторного использования, с «FORCE» все значения в ваших запросах изменяются на переменные связывания. Это действительно удобно, когда ваше приложение не использует переменные связывания. База данных сделает это за вас.
Если вы уже используете cursor_sharing = FORCE. Затем вам нужно начать рассматривать настройку распределения памяти, и в зависимости от параметров памяти, используемых вашей системой, вы можете получить представление о том, где вы должны установить это значение, с помощью следующих запросов:
Когда используются SGA_TARGET и SGA_MAX__SIZE / PGA_TARGET и PGA_MAX_SIZE (они должны совпадать): выберите * из v $ sga_target_advice; выберите * из v $ pga_target_advice;
Это выглядело бы так: в моем случае это система pre prod, она не будет хорошо выглядеть долго:
Строка, где SGA_SIZE_FACTOR равен 1, является текущей настройкой. В системе, где объем памяти меньше, увеличение SGA_SIZE и SGA_SIZE_FACTOR должно показать резкое уменьшение ESTD_DB_TIME и ESTD_DB_TIME_FACTOR. Увеличьте объем памяти до такой степени, что увеличение снова не будет таким большим изменением для времени estd_db_time.
В моем случае здесь, с моей текущей нагрузкой, я мог легко уменьшить размер SGA_TARGET до 80G, не получив большого успеха. Однако снижение его до 57G и менее вызовет все более серьезные проблемы с производительностью.
один или два раза в несколько месяцев эта база данных Oracle XE сообщает об ошибках ORA-4031. Это не указывает на какую-либо конкретную часть sga последовательно. Недавний пример:
ORA-04031: unable to allocate 8208 bytes of shared memory ("large pool","unknown object","sort subheap","sort key")
когда эта ошибка появляется, если пользователь продолжает обновлять, нажав на разные ссылки, они будут как правило, получить больше таких ошибок в разное время, то скоро они получат "404 не найдены" ошибки страницы.
перезапуск базы данных обычно решает проблему на некоторое время, затем через месяц или около того он появляется снова, но редко в том же месте в программе (т. е. он не кажется связанным с какой-либо конкретной частью кода) (приведенный выше пример ошибки был поднят со страницы Apex, которая сортировала 5000+ строк из таблицы).
Я пробовал увеличивать sga_max_size от 140M до 256M и надеюсь, что это поможет. Конечно, я не буду знать, помогло ли это, так как мне пришлось перезапустить базу данных, чтобы изменить настройку :)
Я запускаю Oracle XE 10.2.0.1.0 на коробке Oracle Enterprise Linux 5 с 512 МБ оперативной памяти. Сервер запускает только базу данных Oracle Apex (v3.1.2) и веб-сервер Apache. Я установил его почти со всеми параметрами по умолчанию, и он работает довольно хорошо в течение года или около того. Большинство проблем, которые я смог решить сам, настроив код приложения; он не интенсивно используется и не является критически важной для бизнеса системой.
вот некоторые текущие настройки, которые, я думаю, могут быть актуальными:
если это какая-либо помощь, вот текущие размеры SGA:
даже если вы используете ASMM, вы можете установить минимальный размер для большого пула (MMAN не будет сжимать его ниже этого значения). Вы также можете попробовать закрепить некоторые объекты и увеличить SGA_TARGET.
Не забывайте о фрагментации. Если у вас много трафика, ваши пулы могут быть фрагментированы, и даже если у вас есть несколько свободных МБ, не может быть блока больше 4 КБ. Проверьте размер самого большого свободного блока с запросом типа:
все текущие ответы касаются симптома (исчерпание пула общей памяти), а не проблемы, которая, вероятно, не использует переменные привязки в ваших запросах sql \ JDBC, даже если это не кажется необходимым. Передача запросов без переменных привязки заставляет Oracle каждый раз" жестко анализировать " запрос, определяя его план выполнения и т. д.
некоторые фрагменты из приведенной выше ссылки:
"Java поддерживает переменные bind, ваши разработчики должны начать использовать подготовленные операторы и связывать входы в него. Если вы хотите, чтобы ваша система в конечном итоге масштабировалась за пределами 3 или 4 пользователей - вы сделаете это прямо сейчас (исправьте код). Это не то, о чем нужно думать, это то, что вы должны делать. Побочный эффект это-ваши общие проблемы пула в значительной степени исчезнут. Это первопричина. "
"путь Оракула общий пул (очень важная структура данных общей памяти) operates основан на разработчиках, использующих переменные bind."
" переменные привязки настолько массово важны - я никоим образом не могу переоценивать их важность. "
следующие не нужны, поскольку они не исправляют ошибку:
- 1 PS-ef|grep oracle
- найти smon и убить pid для него
- среда SQL> запуск смонтировать в SQL>
- создать pfile из spfile;
перезапуск базы данных очистит ваш пул, и это решит проблему, а не проблему.
зафиксируйте свой large_pool, чтобы он не мог опуститься ниже определенной точки или добавить память и установить более высокий Макс память.
ошибка: ORA-04031: невозможно выделить 4064 байта общей памяти ("общий пул", " выберите increment$, minvalue, m. ", "SGA heap (3,0)", "kglsim heap")
запущен экземпляр ORACLE.
общая системная глобальная область 4831838208 байт Фиксированный размер 2027320 байт Переменный Размер 4764729544 байты Буферы базы данных 50331648 байт Повторить буферы 14749696 байт База данных подключена. SQL>
ORA-01109: база данных не открыта
база данных отключена. Экземпляр ORACLE выключен.
запущен экземпляр ORACLE.
Общая Глобальная Область Системы 4831838208 байт Фиксированный размер 2027320 байт Переменный размер 4764729544 байт Буферы базы данных 50331648 байт Повторить буферы 14749696 байт База данных подключена. База данных открыта.
Это ошибка Oracle, утечка памяти в shared_pool, скорее всего, db, управляющая множеством разделов. Решение: на мой взгляд, патч не существует, проверьте с поддержкой oracle. Вы можете попробовать с помощью subpools или en (de)able AMM .
Периодические ошибки ORA-04031, с записями в alert.log:
Задача автоматической настройки распределения SGA также страдает в результате недостатка свободной памяти в shared pool — системный процесс MMON по-честному, через общедоступный SQL-интерфейс пытается выполнять задачи и получает ошибки (никаких backdoors ;) — из трейса процесса MMON:
По той же причине shutdown immediate также возвращает ошибку (!):
Для понимания происходивших (в процессе автоматического управления — ASMM) движений памяти внутри SGA, можно посмотреть перераспределение памяти между buffer cache и shared pool (а также долю KGH: NO ACCESS в shared pool) за последние несколько часов:
buffer cache и shared pool фактически менялись размерами несколько раз, т.е. изменения профиля нагрузки были значительными и ASMM «работал очень активно»
Объём KGH: NO ACCESS (области внутри shared pool, выделяемой для блоков данных buffer cache при невозможности в процессе автоматического управления памятью увеличить буферный кэш бд за счёт уменьшения размера shared pool) — более 6ГБ, и продолжал расти:
Операции ASMM по изменению размеров пулов часто заканчивались с ошибками:
В результате память SGA и shared pool, в частности, оказалась распределена следующим образом:
Цифры в последнем запросе выглядят дико нескольно завышенными (см. Bug 4577426 V$SGASTAT may show misleading BYTES values larger than really allocated, исправлен в 11.2.0.2), но пригодны для оценки пропорций распределения компонентов
Как следствие в топе AWR:
— три ожидания из пяти имеют прямое отношение к конкуренции за место в shared pool.
Ожидание SGA: allocation forcing component growth по определению ждёт изменения размеров компонента SGA, проявление событий cursor: pin S wait on X & library cache lock при частых изменениях компонентов SGA и появлении KGH: NO ACCESS описано в High ‘cursor: pin S wait on X’ and/or ‘library cache lock’ Waits Generated by Frequent Shared Pool/Buffer Cache Resize Activity [ID 742599.1], где кроме отключения ASMM рекомендуется уменьшить частоту операций автоматического изменения компонентов разделяемой памяти параметром _memory_broker_stat_interval (по умолчанию — 30 секунд):
Однако, изменение частоты операций управления памятью не поможет решить проблем с возникновением ora-4031, которые, очевидно, связаны с самим функционированием ASMM, и для блокирования возможности повторного возникновения напрашивается и рекомендуется простое и надёжное решение — отключить ASMM и распределять разделяемую память вручную (что уже совсем не радует). Какие ещё варианты предлагают специалисты Oracle?
В документе How To Prevent The Growth Of The Component ‘KGH: NO ACCESS’ In The Shared Pool When ASMM Is Enabled [ID 451960.1] кроме отключения ASMM (первое предлагаемое решение, что странно слышать от производителя фичи, имхо) предлагается и 2-й вполне рабочий вариант — при включенном ASMM установить размеры shared pool и buffer cache (точнее, нижние границы этих пулов) параметрами:
ошибка вызвана старым багом (Bug 9763829 ORA-384 while altering DB_CACHE_SIZE dynamically, согласно описанию исправлен в 11.2.0.2), изменение параметров может потребовать рестартовать бд. Практически интересный результат можно получить после фиксации нижней границы только shared pool параметром shared_pool_size. Результаты распределения компонентов SGA через 2+ недели после установки этого параметра:
Несмотря на значительную долю free memory (2165 из 4096 MB), область KGH: NO ACCESS в составе Shared Pool не появляется вовсе — предполагаю, этому препятствует установленный параметр shared_pool_size при функционирующем ASMM:
— попутная ошибка ORA-48913 вызвана ограничением размера трейса:
, в отличие от описания выраженного в блоках ОС = 512 байт (Oracle 11.1.0.7 Linux x86_64) — см. [ID 30762.1]
Трейс /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_9219.trc достаточно быстро указывает на причину ошибки ORA-600 [kglUnKeepHandle]: (more…)
Комментарии к записи ORA-00600: [kglUnKeepHandle] при превышении лимита количества дочерних курсоров отключены
25.11.2010
ASMM в Oracle 10.2, online отключение в RAC окружении: результаты
В продолжение предыдущей истории с отключением ASMM интересно посмотреть, что получилось в итоге (по отчётам AWR и статистики ОС)
при включенном ASMM, business hours 10:00-13:00 AM, типичные данные за 3 дня
ASMM в Oracle 10.2, online отключение в RAC окружении
Документация Oracle 10g R2 следующим образом описывает Automatic Shared Memory Management (ASMM) в части управления shared pool
… внутренний алгоритм настройки обычно не пытается уменьшить shared pool из-за наличия открытых курсоров (open cursors), фиксированных в памяти (pinned) PL/SQL пакетов и наличия SQL в различных стадиях выполнения, что делает невозможным нахождение гранул памяти, доступных для освобождения. Следовательно, алгоритм автоматической настройки выполняет только увеличение shared pool небольшими порциями, начиная с определённого размера и стабилизируя размер shared pool на оптимальном с позиции производительности уровне
Понятно, что получается, если один из автоматически управляемых компонентов может только увеличиваться (на примере Oracle 10.2.0.4, 2-node RAC, ASMM включен):
29.10.2011
21.11.2010
Oracle 11g: автоматическое управление памятью (ASMM) и serial direct read
Ничем (или недостаточно) ограниченный механизм Automatic Shared Memory Management (ASMM), динамически меняя размеры пулов SGA, может заставить Oracle переключаться между режимами direct path read и кэшированного чтения (через buffer cache SGA), что, в свою очередь, может неожиданно, но вполне заметно влиять на время выполнения типовых запросов
И, хотя в документе High ‘direct path read’ waits in 11g [ID 793845.1] описывается чудесное автоматическое переключение между этими режимами, в зависимости от динамически изменяющегося размера buffer cache:
When ASMM increases the buffer cache due to increased demand, 11g might not again do serial direct path read scans for these same large tables
— в действительности, это только пожелание или план работ на будущее — по крайней мере в версии 11.1.0.7.2 :)
Далее — небольшой практический пример
Комментарии к записи Oracle 11g: автоматическое управление памятью (ASMM) и serial direct read отключены
06.09.2011
ASMM: ORA-04031 и «cursor: pin S wait on X»
Oracle 11.1.0.7.2, Linux x86_64 с работающим Automatic Shared Memory Management (ASMM), некластерный инстанс с меняющимся профилем нагрузки
Периодические ошибки ORA-04031, с записями в alert.log:
Задача автоматической настройки распределения SGA также страдает в результате недостатка свободной памяти в shared pool — системный процесс MMON по-честному, через общедоступный SQL-интерфейс пытается выполнять задачи и получает ошибки (никаких backdoors ;) — из трейса процесса MMON: (more…)
Читайте также: