powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ORA-04030: out of process memory when trying
33 сообщений из 33, показаны все 2 страниц
ORA-04030: out of process memory when trying
    #39694779
Здавствуйте!

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
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
Код: 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.
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


ОС:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
# uname -X
System = SunOS
Release = 5.10
KernelID = Generic_147148-26
Machine = i86pc
NumCPU = 16

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

Не знаю, какие параметры ещё нужно предоставить.
Код: 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.
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 процессов по несколько раз)?
Добавить оперативную память возможности нет.

Заранее благодарен за помощь.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695005
Asmodeus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Хливкие Шорьки,
Как обычно: или увеличивать доступное PGA, или уменьшать потребление со стороны ПО.

Посмотрите потребление памяти сессиями в v$sesstat, statistic# 36.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695070
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг

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

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

Ну, а еще как подсказали (совершенно по-дурацки, но тем не менее) смотреть текущие статистики сессий
А лучше уж и статистики процессов (V$PROCESS)
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695080
Avector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хливкие Шорьки,

Код: plsql
1.
2.
select * from v$process
       order by pga_alloc_mem desc
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695265
Вячеслав ЛюбомудровЧувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг

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

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

Вдогонку ещё вопрос: можно ли сэкономить PGA, перейдя с dedicated server на shared? Если да, какие могут быть подводные камни (например, как при этом будут работать dblinks от/к этой БД с учётом большого tps, не будет ли заморочек при switchover)? Надеюсь, я не слишком многого хочу от уважаемых отвечающих.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695278
Про event 10261 нашёл, в моём случае не походит. :(
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695385
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
# echo '::memstat' | mdb -k
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695403
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зайди в OEM-Server-Memory Advisors, посмотри потребление PGA и максимальное PGA за все время работы.

Посмотри что у тебя с файлом подкачки, недавно было, что база улетела нафиг в даун оттого что файл подкачки был жестко фиксирован.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695406
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
processes обычно сопровождается параметром sessions, который больше его раза в 1.1 примерно

То есть на 1500 процессов у тебя должно быть 1650 сессий.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695416
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет.
(Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому)
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695444
Фотография Vivat!San
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nata44845Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет.
(Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому)

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

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

Только вас там больше не надо.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695670
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если сложно подобрать, то и не надо.
Все таргеты и максы в ноль, кроме
memory_max_target и memory_target
читаем вот это и будет счастье
https://docs.oracle.com/cd/B28359_01/server.111/b28310/memory003.htm#ADMIN11011
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39695676
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
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; 
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39696546
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
A K,

Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40.
Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39696565
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да какие-бы он не задавал параметры, против выжирания памяти какими-нибудь 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';
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39696965
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Накаркала, у меня такое же, причем в основном жрет 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 можно отключить
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697203
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40.

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

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

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

Ну а если разумно - то я не вижу причин не доверять Ораклу, там где это возможно. Из своей парктики -
SGA выше макса подкрутить к сожалению нельзя, не перегружая БД. PGA, через таргет можно увеличивать динамически.
Там где крайне не желательна перегрузка БД, и где в зависимости от ситуации нужна манипуляция PGA - там лучше переходить на раздельное управление. В остальных случаях - можно вполне довериться ораклу. Ну, еще, разве что у вас какие-то редкие настройки под бизнес - тогда вообще лучше от любого автомата отказаться и все области настраивать вручную
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697210
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Понятно, что рельный объем на уровне физики и объем указаный в параметрах БД не совпадают и идет в сторону увеличения на уровне физики. На эту тему есть масса публикаций. Расчитывали и тот и другой объем вполоть до байт. Что бы не нарываться на ошибки с памятью, я , например - на Оракл выделяю на несколько гик меньеш чем у меня оперативы (при условии, что у меня на серваке ничего не крутиться окромя БД). Как, правило, этого воплне хватает что бы не нарваться на подобную ошибку, при условии что сервак исправен конечно.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697315
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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, но память все равно причесать бы.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697317
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697324
Фотография Vadim Lejnin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Народ, при чем здесь VSS?
У ТС - Solaris

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

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

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

Это позволяет, используя ПО сторонних производителей, выполнять «горячее» резервное копирование и восстановление.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697325
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vadim Lejnin,

Пардон, упустила из виду
Значит косяк с VSS только у меня был.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697382
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> 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 не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697388
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем не заморачивайтесь этим и если нет к тому, серьезных оснований - устанавливайте память на автомат!
Еще раз на тесте можете прогнать и убедиться, что в реальности никакого 40 на 60 распределения памяти не существует. У Oracle механизм распределения памяти на автомате - достаточно продвинутая штука, что бы делать подобные глупости в реале. :):)
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697478
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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, и в свою очередь резервирование свопа)
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697691
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Большое спасибо за ссылку на доку - к сожалению все на металинке. Сейчас у меня к нему доступа нет. Так что смог только урывками по инету прочитать. Но, насколько я понял из отрывков - 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 настроены раздельно (так сложилось исторически).
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697783
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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)
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39697922
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вячеслав Любомудров Про жесткое соотношение и реальный объем это ты сам придумал
На самом деле понял из этой цитаты :
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 не использую
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39698168
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Версия до 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
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39698171
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вячеслав Любомудров,

Было такое на 11.2.0.1, очень бесило, что вот она память есть, а оракл SGA не увеличивает, поэтому стала задавать SGA_TARGET вручную. Ну и SGA_MAX_SIZE соответственно.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39698344
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
стоит 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.
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39741815
nata44845
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу VSS под виндой, чтоб не искать, действительно утечка памяти

https://blog.zeddba.com/tag/ora-04030/
...
Рейтинг: 0 / 0
ORA-04030: out of process memory when trying
    #39742198
Фотография Vivat!San
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Убедитесь в корректности установки soft and hard limit of stacksize,
проверьте в соответствии с installation guide для вашей ОС, версии RDBMS.
Используйте HCVE script from RDA - Health Check / Validation Engine Guide ( Doc ID 250262.1 ).
...
Рейтинг: 0 / 0
33 сообщений из 33, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / ORA-04030: out of process memory when trying
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]