Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 ORA-04030: out of process memory when trying  [new]
Хливкие Шорьки
Member

Откуда:
Сообщений: 17
Здавствуйте!

Сегодня получил массу сообщений ORA-04030.

SQL> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Solaris: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

init.ora
+
db_block_size=8192
db_file_multiblock_read_count=128
filesystemio_options=SETALL
db_files=300

java_pool_size=129M
db_cache_size=17G
pga_aggregate_target=4G
sga_target=0
shared_pool_size=1400M
db_keep_cache_size=3G

job_queue_processes=35
large_pool_size=100M
open_cursors=800
processes=1500
cursor_sharing='EXACT'

optimizer_dynamic_sampling=2
optimizer_mode='ALL_ROWS'

session_cached_cursors = 100

_fix_control='5909305:OFF'
_ktb_debug_flags=8


ОС:
# uname -X
System = SunOS
Release = 5.10
KernelID = Generic_147148-26
Machine = i86pc
NumCPU = 16

# prtconf | grep 'Memory size'
Memory size: 65536 Megabytes

Не знаю, какие параметры ещё нужно предоставить.
+
select p.NAME, p.VALUE, p.DISPLAY_VALUE from v$parameter p
where
name like '%size%'
or name like '%target%'
or name like '%shared%'
or name like '%memory%'
or name like '%pga%'
or name like '%sga%'
or name like '%pool%'
or name like '%buf%'
/

NAME VALUE DISPLAY_VALUE
---------------------------------------- -------------------- --------------------
buffer_pool_keep
buffer_pool_recycle
max_shared_servers
global_context_pool_size
shared_server_sessions
max_dump_file_size unlimited unlimited
lock_sga FALSE FALSE
use_indirect_data_buffers FALSE FALSE
pre_page_sga FALSE FALSE
workarea_size_policy AUTO AUTO
create_bitmap_area_size 8388608 8388608
db_block_size 8192 8192
shared_pool_reserved_size 73819750 73819750
sort_area_size 65536 65536
pga_aggregate_target 6442450944 6G
dnfs_batch_size 4096 4096
db_keep_cache_size 3221225472 3G
log_buffer 27033600 27033600
sga_max_size 23420993536 22336M
streams_pool_size 201326592 192M
java_pool_size 201326592 192M
db_cache_size 18052284416 17216M
parallel_execution_message_size 16384 16384
result_cache_max_size 14778368 14432K
shared_pool_size 1476395008 1408M
db_flashback_retention_target 1440 1440
large_pool_size 134217728 128M
hash_area_size 131072 131072
parallel_servers_target 128 128
bitmap_merge_area_size 1048576 1048576
object_cache_optimal_size 102400 102400
object_cache_max_size_percent 10 10
olap_page_pool_size 0 0
client_result_cache_size 0 0
sort_area_retained_size 0 0
shared_memory_address 0 0
shared_servers 0 0
hi_shared_memory_address 0 0
fast_start_mttr_target 0 0
fast_start_io_target 0 0
archive_lag_target 0 0
db_flash_cache_size 0 0
db_recycle_cache_size 0 0
db_32k_cache_size 0 0
db_16k_cache_size 0 0
db_8k_cache_size 0 0
db_4k_cache_size 0 0
db_2k_cache_size 0 0
db_block_buffers 0 0
memory_max_target 0 0
memory_target 0 0
sga_target 0 0
java_max_sessionspace_size 0 0
db_recovery_file_dest_size 0 0


Количество подключений в момент траблов: порядка 1200.

Уважаемые знатоки, какие параметры менять, чтобы увеличить число возможных подключений?
Как узнать, сколько _реально_ памяти занимают сессии (ps выдаёт заведомо большие значения, учитывая объёмы shared memory процессов по несколько раз)?
Добавить оперативную память возможности нет.

Заранее благодарен за помощь.
29 авг 18, 11:23    [21657308]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Asmodeus
Member

Откуда: Минск
Сообщений: 532
Хливкие Шорьки,
Как обычно: или увеличивать доступное PGA, или уменьшать потребление со стороны ПО.

Посмотрите потребление памяти сессиями в v$sesstat, statistic# 36.
29 авг 18, 14:37    [21657695]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17930
Чувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг

Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память.
Товарищи говорят, что предел -- 4GB, я наблюдал 16GB, но это SPARC Solaris

Можно искать по ps -- все что больше 20 гиг -- твои клиенты
Можно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии)

Ну, а еще как подсказали (совершенно по-дурацки, но тем не менее) смотреть текущие статистики сессий
А лучше уж и статистики процессов (V$PROCESS)
29 авг 18, 16:04    [21657843]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Avector
Member

Откуда: Санкт-Петербург
Сообщений: 345
Хливкие Шорьки,

select * from v$process
       order by pga_alloc_mem desc
29 авг 18, 16:12    [21657854]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Хливкие Шорьки
Member

Откуда:
Сообщений: 17
Вячеслав Любомудров
Чувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг

Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память.

Не вижу смысла что-то утаивать, это может препятствовать получению ответа на вопрос. Процессов, не относящихся к Oracle, нет, не считая системных. Кстати, после перезапуска экземпляра освободилось 26 Гигабайт оперативной памяти; не подтверждает ли это версию о не освобождающих память сессиях?

Вячеслав Любомудров
Можно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии)

Можно подробнее? Где возникает этот event и как его пресекать?

Вдогонку ещё вопрос: можно ли сэкономить PGA, перейдя с dedicated server на shared? Если да, какие могут быть подводные камни (например, как при этом будут работать dblinks от/к этой БД с учётом большого tps, не будет ли заморочек при switchover)? Надеюсь, я не слишком многого хочу от уважаемых отвечающих.
30 авг 18, 04:29    [21658316]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Хливкие Шорьки
Member

Откуда:
Сообщений: 17
Про event 10261 нашёл, в моём случае не походит. :(
30 авг 18, 07:12    [21658333]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6751
# echo '::memstat' | mdb -k
30 авг 18, 10:42    [21658540]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Зайди в OEM-Server-Memory Advisors, посмотри потребление PGA и максимальное PGA за все время работы.

Посмотри что у тебя с файлом подкачки, недавно было, что база улетела нафиг в даун оттого что файл подкачки был жестко фиксирован.
30 авг 18, 11:14    [21658576]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
processes обычно сопровождается параметром sessions, который больше его раза в 1.1 примерно

То есть на 1500 процессов у тебя должно быть 1650 сессий.
30 авг 18, 11:19    [21658582]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет.
(Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому)
30 авг 18, 11:36    [21658606]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Vivat!San
Member

Откуда: Отсюда не возвращаются
Сообщений: 503
nata44845
Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет.
(Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому)


А кто же их за Вас подберёт? Неужели срочно Ларри звонить?

А он кстати уже подумал о Вас вот - https://cloud.oracle.com/atp

Только вас там больше не надо.
30 авг 18, 12:08    [21658657]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
Если сложно подобрать, то и не надо.
Все таргеты и максы в ноль, кроме
memory_max_target и memory_target
читаем вот это и будет счастье
https://docs.oracle.com/cd/B28359_01/server.111/b28310/memory003.htm#ADMIN11011
30 авг 18, 16:06    [21659133]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 1700
select name, round(decode(unit, 'bytes', value/1024/1024, value)) value, decode(unit, 'bytes', 'MB', unit) unit from v$pgastat
order by 2 desc; 

select session_id, session_serial#, 
              sql_id,                              -- unique query identifier
              count(*),                            -- approximate number of seconds query was working(*10 if using dba_hist_active_sess_hitory)
              max(pga_allocated),                  -- maximum PGA used by session while performing the query
              max(temp_space_allocated)            -- when query uses  a lot of PGA it usually also utilizes TEMP tablespace
from v$active_session_history                      -- for a post mortem you can use dba_hist_active_sess_hitory which stores each 10th record for a month
where sample_time > sysdate - 1/24                 -- one hour period
group by session_id, session_serial#, sql_id
order by 5 desc nulls last;
              
	   
	-- At the moment usage, more useful in case of PL/SQL collections abuse:
       select s.sid, s.serial#, s.sql_id, round(p.allocated/1024/1024) PGA_MB, p.category 
       from v$process_memory p, v$session s, v$process b
       where p.pid = b.pid and p.serial# = b.serial# and
       b.addr = s.paddr
       order by allocated desc nulls last; 
30 авг 18, 16:10    [21659145]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
A K,

Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40.
Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения.
1 сен 18, 05:58    [21660995]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17930
Да какие-бы он не задавал параметры, против выжирания памяти какими-нибудь 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';
1 сен 18, 09:47    [21661040]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Накаркала, у меня такое же, причем в основном жрет 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 можно отключить
3 сен 18, 06:07    [21662172]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
>Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40.

Откуда такая информация ? На самом деле такое поведение будет зависеть от объемов оперативки для БД и от характера работы с ней.
Если у вас БД имеет пару гик, то приблизительно так и будет. Если десятки гик, то скорее всего PGA останется в раионе 2-4 гб, остальное уйдет на SGA.

>Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения.

Я такой рекомендации не встречал. Скорее наоборот. При memory_target оракл на основе своих метрик сам расчитает сколько ему на что нужно. Ну а вы смотрите сами. Если есть понимание, почему вам нужно самостоятельно управлять размерами, переходите на раздельное управление PGA И SGA.

Ну а если разумно - то я не вижу причин не доверять Ораклу, там где это возможно. Из своей парктики -
SGA выше макса подкрутить к сожалению нельзя, не перегружая БД. PGA, через таргет можно увеличивать динамически.
Там где крайне не желательна перегрузка БД, и где в зависимости от ситуации нужна манипуляция PGA - там лучше переходить на раздельное управление. В остальных случаях - можно вполне довериться ораклу. Ну, еще, разве что у вас какие-то редкие настройки под бизнес - тогда вообще лучше от любого автомата отказаться и все области настраивать вручную
3 сен 18, 14:25    [21662712]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
Понятно, что рельный объем на уровне физики и объем указаный в параметрах БД не совпадают и идет в сторону увеличения на уровне физики. На эту тему есть масса публикаций. Расчитывали и тот и другой объем вполоть до байт. Что бы не нарываться на ошибки с памятью, я , например - на Оракл выделяю на несколько гик меньеш чем у меня оперативы (при условии, что у меня на серваке ничего не крутиться окромя БД). Как, правило, этого воплне хватает что бы не нарваться на подобную ошибку, при условии что сервак исправен конечно.
3 сен 18, 14:31    [21662721]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
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, но память все равно причесать бы.
3 сен 18, 17:52    [21662987]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Не вышло

http://osamamustafa.blogspot.com/2012/11/sgamaxsize-sgatarget-memorytarget.html/
3 сен 18, 17:53    [21662989]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 6427
Народ, при чем здесь VSS?
У ТС - Solaris

Volume Shadow Copy Service (VSS) — это инфраструктуры на платформе Windows Server, которая позволяет приложениям создавать теневые копии (shadow copies). Теневая копия — это согласованный! снимок данных на четко определенный момент времени.

Короче говоря эта инфраструктура позволяет делать согласованные! снимки отдельных файлов или всего тома (диска) без остановки работы. И это обеспечивается ядром ОС Windows.

Сервис Oracle <SID> VSS Writer Service — это сервис Oracle, который обеспечивает координацию между отдельным экземпляром Oracle (на каждый экземпляр создается свой сервис) и VSS инфраструктурой.

Это позволяет, используя ПО сторонних производителей, выполнять «горячее» резервное копирование и восстановление.
3 сен 18, 18:07    [21663007]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Vadim Lejnin,

Пардон, упустила из виду
Значит косяк с VSS только у меня был.
3 сен 18, 18:10    [21663008]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
> 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 не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно.
3 сен 18, 20:21    [21663109]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
В общем не заморачивайтесь этим и если нет к тому, серьезных оснований - устанавливайте память на автомат!
Еще раз на тесте можете прогнать и убедиться, что в реальности никакого 40 на 60 распределения памяти не существует. У Oracle механизм распределения памяти на автомате - достаточно продвинутая штука, что бы делать подобные глупости в реале. :):)
3 сен 18, 20:39    [21663120]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17930
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, и в свою очередь резервирование свопа)
4 сен 18, 04:47    [21663339]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
Большое спасибо за ссылку на доку - к сожалению все на металинке. Сейчас у меня к нему доступа нет. Так что смог только урывками по инету прочитать. Но, насколько я понял из отрывков - The policy is to give 60% to the SGA and 40% to the PGA at startup.
То есть, параметр динамичный. Эти значения плавающие. Что, кстати, автор блога и хочет сказать и что на моей 12ГБ БД и видно.
(На самом деле я свой комент компилировал с автором блога. У него действительно в примере стоит 1Гб общей памяти, у меня на БД 12ГБ. Поэтому тут как бы все смешалось. Сорри.)

Вячеслав, смотрите, у меня 12Гб БД (LINUX RH 6) стоит AMM, паратеры следующие (снял замер только что):
select name, value, display_value from v$parameter v where v.name like '%target%'
sga_target 0 0
memory_target 12884901888 12G
memory_max_target 12884901888 12G
pga_aggregate_target 0 0
То есть на бд жестко задан режим AMM
Теперь:
show sga
Total System Global Area 7695769600 bytes
Fixed Size 2323360 bytes
Variable Size 1182796896 bytes
Database Buffers 6505365504 bytes
Redo Buffers 5283840 bytes

а теперь самое интересное:
select name , value from v$pgastat where name = 'aggregate PGA target parameter'
aggregate PGA target parameter 5154799616

И как бы да - создается впечатление, что имеет место быть соотношение 40 на 60, но:
select name , value from v$pgastat
total PGA allocated 344553472
maximum PGA allocated 500199424
total freeable PGA memory 44236800
PGA memory freed back to OS 9774432256

То есть реально PGA занимает 328Мб.


А если по сути, я хотел донести:
Никакого жесткого соотношения 40 на 60 не существует. Как в примере на моей БД - реальный объем PGA = 328МБ. Безусловно, если интенсивность возрастет, динамически возрастет и PGA. Но, если будет нужно больше памяти для SGA - соответственно вырастет и он.
Насчет использованием под линуксом - Есть несколько баз с AMM (6-12 Гб оперативы). Работает сносно уже несколько лет. Главное как я писал выше, за границы физической памяти не выходить, когда мемори_таргеты выставляешь (отсавляю приблизительно 2-4 гб) Ну, а есть очень большие (до 100гб оперативы), тоже под линуксом - там действительно PGA и SGA настроены раздельно (так сложилось исторически).
4 сен 18, 12:32    [21663778]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17930
A K
Никакого жесткого соотношения 40 на 60 не существует. Как в примере на моей БД - реальный объем PGA = 328МБ. Безусловно, если интенсивность возрастет, динамически возрастет и PGA. Но, если будет нужно больше памяти для SGA - соответственно вырастет и он.
Про жесткое соотношение и реальный объем это ты сам придумал
Есть конкретный алгоритм -- если задано только MEMORY_TARGET, то НАЧАЛЬНОЕ соотношение будет 60/40
Естественно, в процессе работы оно будет меняться в зависимости от нагрузки (более того -- будут меняться размеры компонентов внутри SGA) -- на то это и автоматическое управление памятью.
Вот тебе еще и на Бурлесона ссылочка, он, как обычно перепощивает металинковские ноты своими словами

Дальше, про PGA -- можно вспомнить, что PGA_AGGREGATE_TARGET это желаемое ограничение для всех workarea всех процессов. По умолчанию, размер одной workarea (область для сортировки/хэширования) будет не превышать 5% от PGA_AGGREGATE_TARGET для обычных запросов и 20% для параллельных. Это насчет разницы между TARGET и ALLOCATED

И вот еще -- можно ведь выставить нижние пределы (например DB_CACHE_SIZE, SHARED_POOL_SIZE) -- вот есть подозрение, что при этом неявно выставляется нижний предел SGA_TARGET и SHOW SGA (V$SGA) начинает казать как при выставленном SGA_TARGET. У тебя они точно не установлены ? (show parameter size, только,ради бога, в тегах SRC или хотя бы FIX)
4 сен 18, 14:21    [21664045]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
Вячеслав Любомудров
Про жесткое соотношение и реальный объем это ты сам придумал

На самом деле понял из этой цитаты :
nata44845
помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40.


И поэтому, я и начал объяснять, что это не так (в плане жесткости) и что пугаться 40 на 60 нет никакого смысла. (Не имеет никакого значения то, что возникает при старте, если дальше оно начинает динамически меняться ): причем координальным образом)
В противном случае, не стал бы тратить свое время. И тем более советовать использовать именно этот режим работы, как это и рекомендует оракл, при условии, что нет противопоказаний и человек не очень разбираеться что и на что выделять.

Вячеслав Любомудров
Естественно, в процессе работы оно будет меняться в зависимости от нагрузки (более того -- будут меняться размеры компонентов внутри SGA) -- на то это и автоматическое управление памятью.


Именно этому объяснению я и посвятил предыдущие свои комменты !!!

Вячеслав Любомудров
Вот тебе еще и на Бурлесона ссылочка, он, как обычно перепощивает металинковские ноты своими словами


Благодарю. Я им тоже достаточно часто пользуюсь.

Вячеслав Любомудров

И вот еще -- можно ведь выставить нижние пределы (например DB_CACHE_SIZE, SHARED_POOL_SIZE) -- вот есть подозрение, что при этом неявно выставляется нижний предел SGA_TARGET и SHOW SGA (V$SGA) начинает казать как при выставленном SGA_TARGET. У тебя они точно не установлены ? (show parameter size, только,ради бога, в тегах SRC или хотя бы FIX)


Ну если интересно, то:


SQL> show parameter size;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size integer 1048576
client_result_cache_size big integer 0
create_bitmap_area_size integer 8388608
db_16k_cache_size big integer 0
db_2k_cache_size big integer 0
db_32k_cache_size big integer 0
db_4k_cache_size big integer 0
db_8k_cache_size big integer 0
db_block_size integer 8192
db_cache_size big integer 0
db_flash_cache_size big integer 0
db_keep_cache_size big integer 0
db_recovery_file_dest_size big integer 50000M
db_recycle_cache_size big integer 0
dnfs_batch_size integer 4096
global_context_pool_size string
hash_area_size integer 131072
java_max_sessionspace_size integer 0
java_pool_size big integer 0
large_pool_size big integer 0
max_dump_file_size string unlimited
object_cache_max_size_percent integer 10
object_cache_optimal_size integer 102400
olap_page_pool_size big integer 0
parallel_execution_message_size integer 16384
result_cache_max_size big integer 0
sga_max_size big integer 7372M
shared_pool_reserved_size big integer 60188262
shared_pool_size big integer 0
sort_area_retained_size integer 0
sort_area_size integer 65536
streams_pool_size big integer 0
workarea_size_policy string AUTO


Сразу оговорюсь, что в spfile у меня стоит:
*.sga_max_size=0
*.sga_target=0
прочие перечисленные DB_CACHE_SIZE, SHARED_POOL_SIZE не использую
4 сен 18, 16:26    [21664346]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 17930
Версия до 11.2.0.3 ?
Вот там вроде как если SGA_MAX_SIZE не задан, то он выставляется как 60% MEMORY_TARGET. Начиная с 11.2.0.3 он выставляется равным MEMORY_TARGET (за исключением 32-битной винды). Это вне контекста о изначальном 60/40 для динамических SGA_TARGET/PAT. Это жесткий лимит именно SGA.
Баг или не баг -- хрен знает. Сам не сталкивался. см.https://community.oracle.com/thread/2410066
Поэтому у тебя в выводе V$SGA "Total System Global Area" и не равно MEMORY_TARGET (как раз и равно SGA_MAX_SIZE)

Это, кстати, означает, что SGA_TARGET у тебя никогда не превысит твоих 7.5 гигов, поэтому лучше выставить явно SGA_MAX_SIZE=MEMORY_TARGET
5 сен 18, 07:21    [21664971]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Вячеслав Любомудров,

Было такое на 11.2.0.1, очень бесило, что вот она память есть, а оракл SGA не увеличивает, поэтому стала задавать SGA_TARGET вручную. Ну и SGA_MAX_SIZE соответственно.
5 сен 18, 07:30    [21664976]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
A K
Member

Откуда:
Сообщений: 352
стоит 11.2.0.4.0 - 64bit.
Но не суть. Проблем с этой БД вроде нет. Может быть и баг, а раз баг, то выйдет ли SGA за пределы своего MAX в пределах всего выделенного ему MEMORY - тоже вопрос. В коде ведь никто не копался, как оно реализовано на уровне С/C++ - знает, наверное только тот, кто это писал. Прочему бы и нет :) все эти 40 на 60 - они ведь в официальной доке отсутствуют - нычкуют по металинкам по нотам.

nata44845
Было такое на 11.2.0.1, очень бесило, что вот она память есть, а оракл SGA не увеличивает, поэтому стала задавать SGA_TARGET вручную. Ну и SGA_MAX_SIZE соответственно.


А вы под нагрузкой пробовали на memory_target-е? Может быть под нагрузкой он преодалеет свой макс - "баг ведь :)" - я и такое допускаю, хотя и признаю, что не логично.

Понимаете, если SGA_MAX_SIZE выставлять при выставленном memory_target, тогда зачем вообще нужен memory_target ? Ведь, memory_target везде в доках превозносится как лучшее решение. В принципе на маленьких БД меня устраивает, ну а на больших я использую раздельное управление SGA_TARGET и SGA_MAX_SIZE, PGA_TARGET, но тогда memory_target соответственно в 0.
5 сен 18, 12:12    [21665388]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
По поводу VSS под виндой, чтоб не искать, действительно утечка памяти

https://blog.zeddba.com/tag/ora-04030/
3 дек 18, 06:27    [21751726]     Ответить | Цитировать Сообщить модератору
 Re: ORA-04030: out of process memory when trying  [new]
Vivat!San
Member

Откуда: Отсюда не возвращаются
Сообщений: 503
Убедитесь в корректности установки soft and hard limit of stacksize,
проверьте в соответствии с installation guide для вашей ОС, версии RDBMS.
Используйте HCVE script from RDA - Health Check / Validation Engine Guide ( Doc ID 250262.1 ).
4 дек 18, 02:20    [21752507]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Oracle Ответить