ORA-04030 при заполнении выхода из производства ценами калькуляции : Супермаг Плюс (Супермаг 2000)

В моем случае лучше сделать 6ГБ ?

сделал прям сейчас.

DRIBIN11.__db_cache_size=5452595200
DRIBIN11.__java_pool_size=33554432
DRIBIN11.__large_pool_size=67108864
DRIBIN11.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
DRIBIN11.__pga_aggregate_target=50331648
DRIBIN11.__sga_target=5905580032
DRIBIN11.__shared_io_pool_size=0
DRIBIN11.__shared_pool_size=301989888
DRIBIN11.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/DRIBIN11/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/u01/app/oracle/oradata/DRIBIN11/controlfile/o1_mf_cjnsm4k8_.ctl',$
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_domain=''
*.db_name='DRIBIN11'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=223808061440
*.deferred_segment_creation=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(protocol=TCP)'
*.nls_language='RUSSIAN'
*.nls_territory='RUSSIA'
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.open_cursors=300
*.pga_aggregate_target=34217728
*.processes=200
*.remote_login_passwordfile='EXCLUSIVE'
*.sec_case_sensitive_logon=FALSE
*.sessions=225
*.sga_max_size=5905580032
*.shared_pool_reserved_size=34217728
*.shared_pool_size=290000000
*.shared_servers=2
*.undo_tablespace='UNDOTBS1'

это точно будет лучше, чем нынешние 16Тб в shmall
установишь что-то адекватное и посмотришь как изменится shared memory
откуда она берется сейчас - не очень понятно

поправил на 6 ГБ, вечером перезагружу - посмотрим...

что интересно в /etc/sysctl.conf про эти значения написаны комменты:
# oracle-rdbms-server-11gR2-preinstall setting for kernel.shmmax is 4398046511104 on x86_64
# oracle-rdbms-server-11gR2-preinstall setting for kernel.shmall is 1073741824 on x86_64

Почему 6?! 8 минимум с твоими текущими настройками... Лимит по системе должен быть выше лимита по базе.

я, походу, не совсем правильно понимаю описание переменных... ок, исправлю...

поправил на 9ГБ ... жду ребута

[root@server11ora ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmall = 2359296
fs.file-max = 6815744
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmmax = 9663676416
kernel.panic_on_oops = 1
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500

можете посоветовать, чем можно нагрузить БД? ... рабочий день закончен, юзеров нет.. а на "курящей бд" все летало и раньше

Открой сразу 13 супермагов и запусти выходы эти свои или еще какие-то сводные товарные отчеты с сортировками за большой период. И смотри на RES в столбце top/htop по oracle. Как вылезло за 6Гб - все поправил, значит... В базе лимиты не железные, она за них выходит на раз... Собственно, это не лимиты ни разу.

вот что получилось в пике нагрузки: