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

Поймал ORA-04030



Алерт:

Fri Apr 15 20:34:44 2016
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:
select total_size,awr_flush_emergency_count from v$ash_info;
Fri Apr 15 20:35:05 2016
Errors in file /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/trace/DRIBIN11_s012_18086.trc (incident=13289):
ORA-04030: выход за пределы памяти процесса при попытке выделить 56 байт (callheap,qesaAllocWrkArea:2)
Incident details in: /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/incident/incdir_13289/DRIBIN11_s012_18086_i13289.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/trace/DRIBIN11_s012_18086.trc (incident=13290):
ORA-04030: выход за пределы памяти процесса при попытке выделить 8168 байт (callheap,kdbmal allocation)
ORA-04030: выход за пределы памяти процесса при попытке выделить 56 байт (callheap,qesaAllocWrkArea:2)
Incident details in: /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/incident/incdir_13290/DRIBIN11_s012_18086_i13290.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Fri Apr 15 20:35:14 2016
Dumping diagnostic data in directory=[cdmp_20160415203514], requested by (instance=1, osid=18086 (S012)), summary=[incident=13289].
Errors in file /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/trace/DRIBIN11_s012_18086.trc (incident=13291):
ORA-04030: выход за пределы памяти процесса при попытке выделить 88 байт (kxs-heap-c,kxscomp)
Incident details in: /u01/app/oracle/diag/rdbms/dribin11/DRIBIN11/incident/incdir_13291/DRIBIN11_s012_18086_i13291.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

сделал еще раз пфайл:

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=2147483648
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=223850004480
*.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'

Лечение по фотографии... sysctl -p сейчас какое? дай ему 15Гб по системе. Самописки какие-то есть? посмотри, насколько PGA раздуло, я на Супермаге и солидной БД его видел в максимуме 5Гб. Какой размер БД?

1.
[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

2. Самописок нет.

3. Имеется в виду это?
maximum PGA allocated
7393707008 bytes

4. Оптимизатор говорит, что Database size : 35Gb

5. Дать 15ГБ по системе имеется ввиду shmmax?

по поводу размера БД, если считать его так,

SELECT ROUND(SUM(bytes)/1024/1024/1024, 4) GB
FROM (SELECT SUM(bytes) bytes
FROM dba_data_files
UNION ALL
SELECT SUM(bytes) bytes FROM dba_temp_files
UNION ALL
SELECT SUM(bytes) bytes FROM v$log);

то размер БД 49,9551 ГБ

Загадочно, 35Гб данных, лучше на оптимизаторское ориентироваться, сколько супермагов разом пускал? Да, предлагаю задрать shmmax и shmall до 15Гб, а все клиентские супермаги подключить в SHARED, тут дока есть.

3 супермага ставили цены в инвентаризационные описи на 120000 товаров + 1 алкогольный журнал за 3 месяца + 9 заполняли выход из производтства. По субъективной оценке oracle держался дольше обычного, я даже начал верить, что получилось ))

Ну, как видишь, у тебя 5Гб на sga и 7 на pga в топе...
Но, если всего 3 штуки, то совет с SHARED отменяется... Просто до 15 увеличь... Может засвопаться при виртуалках... Но это, как я понимаю, исключительная ситуация.

не могу найти доку поиском мб опять чего-то недопонимаю..

ОК, спасибо, сегодня после обеда потестим, сейчас сервер не ребутнуть...