Ora 04031 невозможно выделить байт разделяемой памяти

Обновлено: 04.07.2024

Группы пятой тысячи ошибок Oracle (по диапазонам кодов от 4000 до 4999):

Ошибки ORA-04000 - ORA-04099

  • ORA-04000: Сумма PCTUSED и PCTFREE не может превышать 100
  • ORA-04001: Параметр последовательности [значение] должно быть целым числом
  • ORA-04002: INCREMENT должен быть не нулевым целым числом
  • ORA-04003: Параметр последовательности [значение] превышает максимально позволенный ([значение] цифр)
  • ORA-04004: MINVALUE должно быть меньше MAXVALUE
  • ORA-04005: INCREMENT должен быть меньше, чем MAXVALUE минус MINVALUE
  • ORA-04006: START WITH не может быть меньше MINVALUE
  • ORA-04007: MINVALUE не может превышать текущее значение
  • ORA-04008: START WITH не может быть больше MAXVALUE
  • ORA-04009: MAXVALUE не может быть меньше текущего значения
  • ORA-04010: Количество значений CACHE должно быть больше 1
  • ORA-04011: Последовательность [значение] должна быть в диапазоне между [значение] и [значение]
  • ORA-04012: Объект не последовательность
  • ORA-04013: Количество CACHE должно быть меньше чем один цикл
  • ORA-04014: Убывающая последовательность которая CYCLE должна иметь MINVALUE
  • ORA-04014: Убывающая последовательность которая CYCLE должна иметь MINVALUE
  • ORA-04015: Возрастающая последовательность, которая CYCLE должна иметь MAXVALUE
  • ORA-04016: Последовательность [значение] больше не существует
  • ORA-04017: Неверное значение [значение] (длина = [значение]) для параметра max_dump_file_size
  • ORA-04018: Неверное значение [значение] для параметра _scn_scheme
  • ORA-04019: SCN схема не совместима с другими экземплярами
  • ORA-04020: Во время попытки блокировки объекта [значение] обнаружена мертвая блокировка
  • ORA-04021: Истекло время ожидания блокировки объекта
  • ORA-04022: Запрошено без ожидания, но для блокировки объекта словара требуется ожидание
  • ORA-04028: Нельзя сгенерировать DIANA для объекта
  • ORA-04029: Обнаружена ошибка [значение] во время запроса [значение]
  • ORA-04030: Недостаточно памяти во время распределения [значение] байт ([значение],[значение])
  • ORA-04031: Невозможно выделить [значение] байт общей памяти ([значение],[значение],[значение],[значение])
  • ORA-04032: pga_aggregate_target должен быть выставлен до переключения в автоматический режим
  • ORA-04033: Недостаточно памяти для увеличения пула
  • ORA-04041: Описание пакета должно быть создано раньше, чем тело пакета
  • ORA-04042: Процедура, функция, пакет или тело пакета не существует
  • ORA-04043: Объект [значение] не существует
  • ORA-04044: Процедура, функция, пакет или тип не позволены здесь
  • ORA-04045: Ошибки во время перекомпиляции/перепроверки [значение].[значение]
  • ORA-04046: Результаты компиляции слишком большие для поддержки
  • ORA-04047: Указанный объект не совместим с указанным флагом
  • ORA-04050: Неверная или пропущенная процедура, функция или имя пакета
  • ORA-04051: Пользователь [значение] не может использовать ссылку на базу данных [значение].[значение]
  • ORA-04052: Ошибка во время поиска удаленного объекта [значение]
  • ORA-04053: Ошибка во время проверки удаленного объекта [значение]
  • ORA-04054: Ссылка [значение] на базу данных не существует
  • ORA-04060: Недостаточно привилегий для выполнения [значение]
  • ORA-04061: Существующее состояние [значение] было признано недействительным
  • ORA-04062: %s [значение] было изменено
  • ORA-04063: %s содержит ошибки
  • ORA-04064: Не выполнено, неверная [значение]
  • ORA-04065: Не выполнена, изменена или удалена [значение]
  • ORA-04066: Неисполняемый объект, [значение]
  • ORA-04067: Не выполнено, [значение] не существует
  • ORA-04068: Существующее состояние пакетов [значение] было сброшено
  • ORA-04070: Неверное имя триггера
  • ORA-04071: Пропущено ключевое слово BEFORE, AFTER или INSTEAD
  • ORA-04072: Неверный тип триггера
  • ORA-04073: Список колонок не верен для этого типа триггера
  • ORA-04074: Неверное имя для REFERENCING
  • ORA-04075: Неверное действие триггера
  • ORA-04076: Неверная спецификация NEW или OLD
  • ORA-04077: Предложение WHEN не может быть использовано с триггерами уровня таблиц
  • ORA-04078: Значения OLD и NEW не могут быть идентичными
  • ORA-04079: Неверная спецификация триггера
  • ORA-04080: Триггер [значение] не существует
  • ORA-04081: Триггер [значение] уже существует
  • ORA-04082: Ссылки NEW или OLD не позволены в триггерах уровня таблиц
  • ORA-04083: Неверная переменная [значение] триггера
  • ORA-04084: Нельзя сменить значения для NEW в этом типе триггера
  • ORA-04085: Нельзя сменить значение OLD ссылающейся переменной
  • ORA-04086: Описание триггера слишком длинное, переместите комментарии в код триггера
  • ORA-04087: Нельзя изменить значение ROWID
  • ORA-04088: Ошибка во время исполнения триггера [значение].[значение]
  • ORA-04089: Нельзя создать триггеры на объекты принадлежащие SYS
  • ORA-04090: [значение] определяет ту же таблицу, событие и время триггера что и [значение]
  • ORA-04091: Таблица [значение].[значение] изменяется, триггер/функция могут не видеть ее
  • ORA-04092: Нельзя [значение] в триггере
  • ORA-04093: В триггерах не позволены ссылки на колонки с типом LONG
  • ORA-04094: Таблица [значение].[значение] ограничена, триггер не может изменить ее
  • ORA-04095: Триггер [значение] уже существует на другой таблице, нельзя заменить его
  • ORA-04096: Триггер [значение] содержит предложение WHEN которое слишком большое, предел 2K
  • ORA-04097: DDL конфликт во время удаления или изменения триггера
  • ORA-04098: Триггер [значение].[значение] не верен и повторная проверка провалена
  • ORA-04099: Триггер [значение] верен, но не сохранен в компилированной форме

Ошибки ORA-04900 - ORA-04999

На правах рекламы (см. условия): ◀ ◀ ◀ Место для размещения коммерческих ссылок (см. , пожалуйста, условия) ▶ ▶ ▶ -->

SELECT P1.FFIO,PASS.FNMB,C1.FNREC REC1
FROM GAL.PERSONS@GAL P1,GAL.PERSONS@GAL P2,
GAL.CATALOGS@GAL C1,GAL.CATALOGS@GAL C2,
GAL.APPOINTMENTS@GAL A1,GAL.APPOINTMENTS@GAL A2,
GAL.PASSPORTS@GAL PASS
WHERE (P1.FAPPOINTCUR = A1.FNREC AND A1.FPOST = C1.FNREC) AND
(P2.FAPPOINTCUR=A2.FNREC AND A2.FDEPARTMENT=C2.FNREC)AND
(A1.FNREC=A2.FNREC AND
P1.FNREC= PASS.FPERSON AND PASS.FSYSCODE='501')
MINUS
SELECT TEXT, '', '' FROM INFORMATION;

В ОТВЕТ ПОЛУЧАЮ
_____________________________________________________________
The following error has occurred:

use the DBMS_SHARED_POOL package to pin large packages

т.к. ПК с 256 МБ ОЗУ а на нём полностью кручу 3-х звенку, после загрузки ПК сразу суммарное использование памяти

Ты меня не совсем понял. Здесь речь не идет о нехватки реальной оперативной памяти как таковой. Ораклу операционка выделила ему причитающиеся 18897920(shared_pool_size)+bla bla bla. Где - в ОЗУ или в apge/swap файле это уже дело десятое, но как факт память для shared_pool_size в размере 18897920 у Оракла есть.

Проблема в том что в этом пуле размером 18897920 может просто не оказаться непрерывного свободного места для размещения большого объекта из за сильной фрагментации, хотя его суммарный размер может быть вполне достаточным. Если такого места нет, Оракл не будет расширять shared_pool а выдаст ошибку.

PS
Есть программеры которые решают эту проблему периодических вызовом

alter system flush shared_pool;

Советую прочесть 2 книги Тома Кайта а потом приступить к настройкам такого рода. Книги есть на русском.

Oracle9i Database Concepts
Release 2 (9.2)
Part Number A96524-01
7
Memory Architecture
This chapter discusses the memory architecture of an Oracle instance. It includes:

Да, жесток Скотти
Только нигде я не встретил там упоминания о flush shared_pool. Периодическое (скажем, раз в сутки) его выполнение - весчь даже очень-таки пользительная.
То бишь - это есть благо, если не увлекаться ;)
А то я уж решил, что хана Адамсу - выпустит и ему :)

2. Либо поставить в инишник вот такой скрытый параметр
_db_handles_cached = 0

и посмотреть что получится.

Я не имел в виду применительно к flush shared_pool, а его методы, которые он практикует, в общем случае.

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

один или два раза в несколько месяцев эта база данных 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. 1 PS-ef|grep oracle
  2. найти smon и убить pid для него
  3. среда SQL> запуск смонтировать в SQL>
  4. создать pfile из spfile;

перезапуск базы данных очистит ваш пул, и это решит проблему, а не проблему.

зафиксируйте свой large_pool, чтобы он не мог опуститься ниже определенной точки или добавить память и установить более высокий Макс память.

ошибка: ORA-04031: невозможно выделить 4064 байта общей памяти ("общий пул", " выберите increment$, minvalue, m. ", "SGA heap (3,0)", "kglsim heap")

запущен экземпляр ORACLE.

общая системная глобальная область 4831838208 байт Фиксированный размер 2027320 байт Переменный Размер 4764729544 байты Буферы базы данных 50331648 байт Повторить буферы 14749696 байт База данных подключена. SQL>

Это ошибка Oracle, утечка памяти в shared_pool, скорее всего, db, управляющая множеством разделов. Решение: на мой взгляд, патч не существует, проверьте с поддержкой oracle. Вы можете попробовать с помощью subpools или en (de)able AMM .

Когда я работал над проектом сегодня, потому что я изменил IP-адрес удаленного доступа, я продолжал сообщать о следующих ошибках:

Baidu не работает Были найдены следующие решения:
1.ORACLE BUG
Oracle рекомендует последний пакет исправлений для вашей системы. Большинство ошибок ORA-04031 связано с ошибками, и их можно избежать с помощью этих исправлений.

В следующей таблице приведены наиболее распространенные ошибки, возможные среды и исправления, которые устраняют эту проблему.

Ошибка Описание Обходной путь Исправлен
<Bug:1397603> ORA-4031/SGA memory leak of PERMANENT memory occurs for buffer handles _db_handles_cached = 0 901/ 8172
<Bug:1640583> ORA-4031 due to leak / cache buffer chain contention from AND-EQUAL access Not available 8171/901
<Bug:1318267> 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
<Bug:1193003> Cursors may not be shared in 8.1
when they should be Not available 8162/8170/ 901
<Bug:2104071> ORA-4031/excessive "miscellaneous" shared pool usage possible. (many PINS) None-> This is known to affect the XML parser. 8174, 9013, 9201
<Note:263791.1> 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%, попробуйте уменьшить потерю кэша библиотеки, увеличив размер общего пула.

Расчет размера общего пула
Чтобы рассчитать размер общего пула, который лучше всего подходит для вашей рабочей нагрузки, обратитесь к:

<Note:1012046.6>: HOW TO CALCULATE YOUR SHARED POOL SIZE.
Фрагментация общего пула
Каждый раз анализируемая форма оператора SQL или PL / SQL, который необходимо выполнить, загружает определенный непрерывный пробел в общий пул. Первый ресурс, который будет проверен базой данных, - это свободная доступная память в общем пуле. Как только свободная память исчерпана, база данных должна найти часть памяти, которая была выделена, но еще не использована для повторного использования. Если такой большой блок точного размера недоступен, продолжайте поиск по следующим критериям:

Размер чанка больше, чем запрашиваемый размер
Пространство непрерывно
Большие блоки памяти доступны (вместо того, чтобы использоваться)
Таким образом, большие блоки памяти разделяются, а остальное добавляется в соответствующий список свободного места. Когда база данных работает таким образом в течение определенного периода времени, в структуре общего пула происходит фрагментация.

Когда существует проблема фрагментации в общем пуле, потребуется больше времени для выделения свободного пространства, и производительность базы данных также снизится (в течение всей операции «выделение чанков» контролируется защелкой, называемой «защелкой общего пула») Или это ошибки ORA-04031 (когда база данных не может найти непрерывный блок свободной памяти).

См. <Примечание: 61623.1>: вы можете получить подробное обсуждение фрагментации общего пула.
Если SHARED_POOL_SIZE достаточно велик, большинство ошибок ORA-04031 вызвано динамической фрагментацией SQL в общем пуле. Возможные причины следующие:
Неподеленный SQL
Генерация ненужных вызовов синтаксического анализа (мягкий анализ)
Переменная связывания не используется
Чтобы уменьшить образование мусора, необходимо определить возможные факторы, описанные выше. Конечно, вы можете использовать следующие методы, не ограничиваясь этими типами: настройка приложения, настройка базы данных или настройка параметров экземпляра.

Пожалуйста, обратитесь к <Примечание: 62143.1>, где описаны все эти детали. В этом примечании также содержатся сведения о том, как работает общий пул.
Следующее представление помогает пометить неиспользуемый 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 кучи)
Используя это представление, можно узнать выделенное в настоящее время свободное пространство, что помогает понять степень фрагментации общего пула. Как мы описывали ранее, первое место, где нужно найти достаточно большой объем памяти, выделенный для курсора, - это свободный список. Следующее утверждение показывает большой блок памяти в свободном списке:

Читайте также: