Ответ 1
Даже если вы используете ASMM, вы можете установить минимальный размер для большого пула (MMAN не будет уменьшать его ниже этого значения). Вы также можете попробовать укрепить некоторые объекты и увеличить SGA_TARGET.
Мне нужно несколько указателей на то, как диагностировать и исправлять эту проблему. Я не знаю, является ли это простой проблемой установки сервера или проблемой дизайна приложения (или и того и другого).
Один или два раза каждые несколько месяцев эта база данных 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. Я установил его с почти всеми параметрами по умолчанию, и он работал довольно хорошо в течение года или около того. Большинство проблем, которые я смог решить, настраивая код приложения; он не интенсивно используется и не является критически важной для бизнеса системой.
Вот некоторые текущие настройки, которые, я думаю, могут иметь значение:
pga_aggregate_target 41,943,040
sga_max_size 268,435,456
sga_target 146,800,640
shared_pool_reserved_size 5,452,595
shared_pool_size 104,857,600
Если это поможет здесь текущие размеры SGA:
Total System Global Area 268435456 bytes
Fixed Size 1258392 bytes
Variable Size 251661416 bytes
Database Buffers 12582912 bytes
Redo Buffers 2932736 bytes
Даже если вы используете ASMM, вы можете установить минимальный размер для большого пула (MMAN не будет уменьшать его ниже этого значения). Вы также можете попробовать укрепить некоторые объекты и увеличить SGA_TARGET.
Не забывайте о фрагментации. Если у вас много трафика, ваши пулы могут быть фрагментированы, и даже если у вас есть несколько MB бесплатно, не может быть блока размером больше 4 КБ. Проверьте размер самого большого свободного блока с запросом типа:
select
'0 (<140)' BUCKET, KSMCHCLS, KSMCHIDX,
10*trunc(KSMCHSIZ/10) "From",
count(*) "Count" ,
max(KSMCHSIZ) "Biggest",
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ<140
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 10*trunc(KSMCHSIZ/10)
UNION ALL
select
'1 (140-267)' BUCKET,
KSMCHCLS,
KSMCHIDX,
20*trunc(KSMCHSIZ/20) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 140 and 267
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 20*trunc(KSMCHSIZ/20)
UNION ALL
select
'2 (268-523)' BUCKET,
KSMCHCLS,
KSMCHIDX,
50*trunc(KSMCHSIZ/50) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 268 and 523
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 50*trunc(KSMCHSIZ/50)
UNION ALL
select
'3-5 (524-4107)' BUCKET,
KSMCHCLS,
KSMCHIDX,
500*trunc(KSMCHSIZ/500) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 524 and 4107
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 500*trunc(KSMCHSIZ/500)
UNION ALL
select
'6+ (4108+)' BUCKET,
KSMCHCLS,
KSMCHIDX,
1000*trunc(KSMCHSIZ/1000) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ >= 4108
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 1000*trunc(KSMCHSIZ/1000);
Все текущие ответы устраняют симптом (исчерпание пула разделяемой памяти), а не проблему, которая, вероятно, не использует переменные связывания в ваших запросах sql\JDBC, даже если это не представляется необходимым. Передача запросов без переменных привязки заставляет Oracle "жестко разобрать" запрос каждый раз, определяя его план выполнения и т.д.
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::p11_question_id:528893984337
Некоторые фрагменты из приведенной выше ссылки:
"Java поддерживает переменные связывания, ваши разработчики должны начать использовать подготовленные операторы и связывать с ними входы. Если вы хотите, чтобы ваша система в конечном счете уменьшилась, скажем, около 3 или 4 пользователей, вы сделаете это прямо сейчас (исправьте код) Это не то, о чем нужно думать, это то, что вы ДОЛЖНЫ делать. Побочный эффект этого - ваши проблемы с общим пулом в значительной степени исчезнут. Это основная причина."
"Как Oracle общий пул (очень важная структура данных разделяемой памяти) работает на разработчиков, использующих переменные связывания.
"Связанные переменные SO MASSIVELY важны - я никоим образом не могу сформировать или сформировать значение OVERSTATE их важности".
Следующие не нужны, так как они не исправляют ошибку:
ps -ef|grep oracle
SQL> startup mount
SQL> create pfile from spfile;
Перезапуск базы данных очистит ваш пул, и это решит проблему, а не проблему.
Исправьте ваш large_pool так, чтобы он не мог опуститься ниже определенной точки или добавьте память и установите более высокий максимальный объем памяти.
ОшибкаORA-04031: unable to allocate 4064 bytes of shared memory ("shared pool","select increment$,minvalue,m...","sga heap(3,0)","kglsim heap")
1.-
ps -ef|grep oracle
2.- Найти сына и убить пид за него
3.-
SQL> startup mount
ORACLE instance started.
Total System Global Area 4831838208 bytes
Fixed Size 2027320 bytes
Variable Size 4764729544 bytes
Database Buffers 50331648 bytes
Redo Buffers 14749696 bytes
Database mounted.
4.-
SQL> alter system set shared_pool_size=100M scope=spfile;
System altered.
5.-
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
6.-
SQL> startup
ORACLE instance started.
Total System Global Area 4831838208 bytes
Fixed Size 2027320 bytes
Variable Size 4764729544 bytes
Database Buffers 50331648 bytes
Redo Buffers 14749696 bytes
Database mounted.
Database opened.
7.-
SQL> create pfile from spfile;
File created.
РЕШИТЬ
Это ошибка Oracle, утечка памяти в shared_pool, скорее всего, db управляет множеством разделов. Решение. На мой взгляд, патч не существует, проверьте поддержку oracle. Вы можете попробовать с помощью subpools или en (de) способных AMM...