|
|
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Здавствуйте! Сегодня получил массу сообщений ORA-04030. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. init.ora Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ОС: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Не знаю, какие параметры ещё нужно предоставить. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. Количество подключений в момент траблов: порядка 1200. Уважаемые знатоки, какие параметры менять, чтобы увеличить число возможных подключений? Как узнать, сколько _реально_ памяти занимают сессии (ps выдаёт заведомо большие значения, учитывая объёмы shared memory процессов по несколько раз)? Добавить оперативную память возможности нет. Заранее благодарен за помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 11:23 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Хливкие Шорьки, Как обычно: или увеличивать доступное PGA, или уменьшать потребление со стороны ПО. Посмотрите потребление памяти сессиями в v$sesstat, statistic# 36. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 14:37 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Чувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память. Товарищи говорят, что предел -- 4GB, я наблюдал 16GB, но это SPARC Solaris Можно искать по ps -- все что больше 20 гиг -- твои клиенты Можно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии) Ну, а еще как подсказали (совершенно по-дурацки, но тем не менее) смотреть текущие статистики сессий А лучше уж и статистики процессов (V$PROCESS) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 16:04 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Хливкие Шорьки, Код: plsql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 16:12 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЧувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память. Не вижу смысла что-то утаивать, это может препятствовать получению ответа на вопрос. Процессов, не относящихся к Oracle, нет, не считая системных. Кстати, после перезапуска экземпляра освободилось 26 Гигабайт оперативной памяти; не подтверждает ли это версию о не освобождающих память сессиях? Вячеслав ЛюбомудровМожно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии) Можно подробнее? Где возникает этот event и как его пресекать? Вдогонку ещё вопрос: можно ли сэкономить PGA, перейдя с dedicated server на shared? Если да, какие могут быть подводные камни (например, как при этом будут работать dblinks от/к этой БД с учётом большого tps, не будет ли заморочек при switchover)? Надеюсь, я не слишком многого хочу от уважаемых отвечающих. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 04:29 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Про event 10261 нашёл, в моём случае не походит. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 07:12 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 10:42 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Зайди в OEM-Server-Memory Advisors, посмотри потребление PGA и максимальное PGA за все время работы. Посмотри что у тебя с файлом подкачки, недавно было, что база улетела нафиг в даун оттого что файл подкачки был жестко фиксирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:14 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
processes обычно сопровождается параметром sessions, который больше его раза в 1.1 примерно То есть на 1500 процессов у тебя должно быть 1650 сессий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:19 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет. (Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:36 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
nata44845Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет. (Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому) А кто же их за Вас подберёт? Неужели срочно Ларри звонить? А он кстати уже подумал о Вас вот - https://cloud.oracle.com/atp Только вас там больше не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 12:08 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Если сложно подобрать, то и не надо. Все таргеты и максы в ноль, кроме memory_max_target и memory_target читаем вот это и будет счастье https://docs.oracle.com/cd/B28359_01/server.111/b28310/memory003.htm#ADMIN11011 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 16:06 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 16:10 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K, Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40. Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2018, 05:58 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Да какие-бы он не задавал параметры, против выжирания памяти какими-нибудь PL/SQL-таблицами до 12c был только вариант event 10261 . Да и все приводимые запросы мало чем помогут в анализе древней ситуации А вот почему ОС не смогла отдать столько памяти, тут другой вопрос. Как минимум надо настроить тот-же sar (в солярке обычно достаточно просто раскомментировать соответствующие строки в crontab от sys ). Можно периодически сбрасывать информацию о наиболее жрущих процессах в ОС ( ps -eo vsz,user,args | sort -n | tail -5 ). Не забыть только время указывать :-). Можно также периодически запрашивать структуру памяти, как показал Scott Tiger , если не хватает того же sar (в обоих случаях тот же ненастроенный ZFS ARC съест все неиспользуемую память, так что свободной памяти практически не будет). Конечно, если все это случается нечасто, надо предусмотреть какую-либо ротацию всех этих отчетов А есть вариант, что это попытка превышения oracle process memory limit (ни в коей мере ни соотносится с PGA_AGGREGETE_TARGET). На Solaris SPARC я наблюдал до 16 GB, хотя встречалось утверждение, что максимум -- это 4GB. Это именно память в куче. Т.е. если мы видим в ps процесс с vsz больше чем SGA плюс несколько гигов -- как правило, это уже наш поциент. В этом тоже может помочь периодический сбор информации о процессах ОС PS. можно заставить сбрасывать трассу, чтоб посмотреть где и когда это случилось https://blogs.oracle.com/db/ora-4030-troubleshooting To setup tracing to trap the ORA-4030, on the server use the following in SQLPlus: alter system set events '4030 trace name heapdump level 536870917;name errorstack level 3'; Once the error reoccurs with the event set, you can turn off tracing using the following command in SQLPlus: alter system set events '4030 trace name context off; name context off'; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2018, 09:47 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Накаркала, у меня такое же, причем в основном жрет oravssv, цитирую Дмитрия БобровскогоЕсли резервирование выполняется без использования VSS, лучше отключить или вообще удалить эти службы Oracle <SID> VSS Writer Service. Т.к. они потребляют ресурсы. А так же возможна утечка памяти (unpublished Bug:9063341) — Instance Crash Or ORA-04030 Errors When Pagefile Is Full [ID 1358570.1] или Bug 10209909 : ORAVSSW PROCESS CONSUME ALL MEMORY Посмотрела другие сервера, там служба вручную стоит на запуск По идее если пользуемся RMAN можно отключить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 06:07 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
>Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40. Откуда такая информация ? На самом деле такое поведение будет зависеть от объемов оперативки для БД и от характера работы с ней. Если у вас БД имеет пару гик, то приблизительно так и будет. Если десятки гик, то скорее всего PGA останется в раионе 2-4 гб, остальное уйдет на SGA. >Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения. Я такой рекомендации не встречал. Скорее наоборот. При memory_target оракл на основе своих метрик сам расчитает сколько ему на что нужно. Ну а вы смотрите сами. Если есть понимание, почему вам нужно самостоятельно управлять размерами, переходите на раздельное управление PGA И SGA. Ну а если разумно - то я не вижу причин не доверять Ораклу, там где это возможно. Из своей парктики - SGA выше макса подкрутить к сожалению нельзя, не перегружая БД. PGA, через таргет можно увеличивать динамически. Там где крайне не желательна перегрузка БД, и где в зависимости от ситуации нужна манипуляция PGA - там лучше переходить на раздельное управление. В остальных случаях - можно вполне довериться ораклу. Ну, еще, разве что у вас какие-то редкие настройки под бизнес - тогда вообще лучше от любого автомата отказаться и все области настраивать вручную ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 14:25 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Понятно, что рельный объем на уровне физики и объем указаный в параметрах БД не совпадают и идет в сторону увеличения на уровне физики. На эту тему есть масса публикаций. Расчитывали и тот и другой объем вполоть до байт. Что бы не нарываться на ошибки с памятью, я , например - на Оракл выделяю на несколько гик меньеш чем у меня оперативы (при условии, что у меня на серваке ничего не крутиться окромя БД). Как, правило, этого воплне хватает что бы не нарваться на подобную ошибку, при условии что сервак исправен конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 14:31 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K, Видимо отсюда SGA_TARGET, SGA_MAX_SIZE and PGA_AGGREGATE_TARGET are set to 0, 60% of memory mentioned in MEMORY_TARGET is allocated to SGA and rest 40% is kept for PGA. Ссылка А вообще автор пропал, теперь более чем уверена, что у него дело не в памяти, а в Oracle VSS, но память все равно причесать бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 17:52 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 17:53 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Народ, при чем здесь VSS? У ТС - Solaris Volume Shadow Copy Service (VSS) — это инфраструктуры на платформе Windows Server, которая позволяет приложениям создавать теневые копии (shadow copies). Теневая копия — это согласованный! снимок данных на четко определенный момент времени. Короче говоря эта инфраструктура позволяет делать согласованные! снимки отдельных файлов или всего тома (диска) без остановки работы. И это обеспечивается ядром ОС Windows. Сервис Oracle <SID> VSS Writer Service — это сервис Oracle, который обеспечивает координацию между отдельным экземпляром Oracle (на каждый экземпляр создается свой сервис) и VSS инфраструктурой. Это позволяет, используя ПО сторонних производителей, выполнять «горячее» резервное копирование и восстановление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 18:07 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin, Пардон, упустила из виду Значит косяк с VSS только у меня был. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 18:10 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
> http://osamamustafa.blogspot.com/2012/11/sgamaxsize-sgatarget-memorytarget.html ну это частное мнение хозяина блога (который не разобрался как следует в очень интересной тематике). Хотелось бы правило 60 на 40 увидеть в официальной документации (думал на винде такая ерундовина - у меня БД стоят на линуксе). Сегодня специально искал, но не нашел и не найду :). Потому, что: https://blog.dbi-services.com/oracle-automatic-memory-management-monitoring-the-memory-usage/ Внимательно прочитайте этот блог. Вам все станет ясно как Оракл распределяет на автомате память и необычность поведения значения параметров, которые ранее были предельно понятны. А теперь практика: У меня на одной из БД, где 12Гб оперативы ситуация следующая (memory_max_target = 12G и memory_target = 12G), далее select * from V$MEMORY_DYNAMIC_COMPONENTS 5 SGA Target 7730102272 7730102272 7730102272 0 0 STATIC 4194304 15 PGA Target 5154799616 5154799616 5154799616 0 0 STATIC 4194304 Похоже правда на 60 и 40, но :) А теперь посмотрим что и сколько реально занимает: select name , value from v$pgastat where name = 'total PGA allocated' 1 total PGA allocated 297175040 Уже и никакие не 40 процентов :) а теперь делаем вот это - show sga Total System Global Area 7695769600 bytes Fixed Size 2323360 bytes Variable Size 1249905760 bytes Database Buffers 6438256640 bytes Redo Buffers 5283840 bytes Как же нам это понимать? : variable size = current SGA + what could be stolen to the PGA .ndeed, it considers that the variable size might grow up to 1249905760 bytes, leading to a PGA reduction to 0! The information “Total System Global Area” must be interpreted with care! Ну вот как то так. Просто нужно понимать что таргеты - это одно, а реальный объем это другое. Еще раз обратите внимание какой реальный расклад для PGA на 12Гб мемори_таргета: select name , value from v$pgastat 1 aggregate PGA target parameter 5154799616 5 total PGA allocated 360601600 6 maximum PGA allocated 411419648 То есть 5 гб (40 процентов) он как бы может отожрать, но в реальности отжирает только 360М Скорее всего, при нормальном раскладе в реальной жизни он вряд ли отожрет больше 1Гб - если внутренние таргет адвайсеры скажут это сделать. Ну и соответственно SGA не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 20:21 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
В общем не заморачивайтесь этим и если нет к тому, серьезных оснований - устанавливайте память на автомат! Еще раз на тесте можете прогнать и убедиться, что в реальности никакого 40 на 60 распределения памяти не существует. У Oracle механизм распределения памяти на автомате - достаточно продвинутая штука, что бы делать подобные глупости в реале. :):) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 20:39 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K> http://osamamustafa.blogspot.com/2012/11/sgamaxsize-sgatarget-memorytarget.html ну это частное мнение хозяина блога (который не разобрался как следует в очень интересной тематике). Хотелось бы правило 60 на 40 увидеть в официальной документации (думал на винде такая ерундовина - у меня БД стоят на линуксе). Сегодня специально искал, но не нашел и не найду :). Automatic Memory Management (AMM) SGA and PGA Management in 11g and Above (Doc ID 1392549.1) Automatic Memory Management (AMM) on 11g & 12c (Doc ID 443746.1) A K https://blog.dbi-services.com/oracle-automatic-memory-management-monitoring-the-memory-usage/ Внимательно прочитайте этот блог. Вам все станет ясно как Оракл распределяет на автомате память и необычность поведения значения параметров, которые ранее были предельно понятны.Тут только ясно, что автор неправильно интерпретирует “variable size = current SGA + what could be stolen to the PGA” У него все четко по цифрам: Total System Global Area = memory_target = Fixed Size + Redo Buffers + Database Buffers + Variable Size Где Variable Size = Shared pool + Large pool + Other pools (Java, Streams, Result cache) + Свободное место, которое пока отдано под PGA (workareas) A KА теперь практика: У меня на одной из БД, где 12Гб оперативы ситуация следующая (memory_max_target = 12G и memory_target = 12G), далее select * from V$MEMORY_DYNAMIC_COMPONENTS 5 SGA Target 7730102272 7730102272 7730102272 0 0 STATIC 4194304 15 PGA Target 5154799616 5154799616 5154799616 0 0 STATIC 4194304 Похоже правда на 60 и 40, но :) А теперь посмотрим что и сколько реально занимает: select name , value from v$pgastat where name = 'total PGA allocated' 1 total PGA allocated 297175040 Уже и никакие не 40 процентов :) а теперь делаем вот это - show sga Total System Global Area 7695769600 bytes Fixed Size 2323360 bytes Variable Size 1249905760 bytes Database Buffers 6438256640 bytes Redo Buffers 5283840 bytes Как же нам это понимать? : variable size = current SGA + what could be stolen to the PGA .ndeed, it considers that the variable size might grow up to 1249905760 bytes, leading to a PGA reduction to 0! The information “Total System Global Area” must be interpreted with care! Ну вот как то так. Просто нужно понимать что таргеты - это одно, а реальный объем это другое. Еще раз обратите внимание какой реальный расклад для PGA на 12Гб мемори_таргета: select name , value from v$pgastat 1 aggregate PGA target parameter 5154799616 5 total PGA allocated 360601600 6 maximum PGA allocated 411419648 То есть 5 гб (40 процентов) он как бы может отожрать, но в реальности отжирает только 360М Скорее всего, при нормальном раскладе в реальной жизни он вряд ли отожрет больше 1Гб - если внутренние таргет адвайсеры скажут это сделать. Ну и соответственно SGA не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно.Что-то никак не бъется Total System Global Area с memory_target Очень похоже, что это вывод с другой БД, без AMM И тогда 1249905760 (а это ~1 Гиг, а не 12 ) -- это размер Shared pool + Large pool + Other pools (Java, Streams, Result cache) безо всякого PGA К тому же стоит различать PGA workareas, которые рулятся PGA_AGGREGATE_TARGET / MEMORY_TARGET и которые используются для операций сортировки/хэширования и Private SQL Area (которые тоже являются частью PGA процесса), которые не обращают никакого внимания на эти установки. К тому же, у автора AMM вообще не используется (да и смысл использования его под линуксом/солярисом вызывает большие сомнения -- в линуксе это отказ от HugePages, в солярке -- использование DISM, и в свою очередь резервирование свопа) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2018, 04:47 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39695416&tid=1883087]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
41ms |
get tp. blocked users: |
2ms |
| others: | 244ms |
| total: | 356ms |

| 0 / 0 |
