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

Столкнулся с вышеуказанной проблемой. Проблема появляется, только в рабочее время, когда работают все пользователи 13 ПК, и при условии заполнения выхода более 200 позиций (заполняю 150 - все ок). В не рабочее время заполнение пролетает даже на 1000 позиций.
Почитав про эту ошибку на форуме и не только пытался перестроить перераспределить память в oracle и настроить shell limits в ОС, но это ни к чему не привело (походу мозгов не хватает).
Поставил Оптимизатор-7, он поменял распределение памяти, но проблема не ушла.

Конфигурация:
1. Linux version 3.8.13-44.1.1.el6uek.x86_64 (mockbuild@ca-build44.us.oracle.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3)

2. Oracle 11.2.0.3.0 - 64bit

3. Память
total used free shared buffers cached
Mem: 16143640 12626248 3517392 5671732 35792 9461536
-/+ buffers/cache: 3128920 13014720
Swap: 16383996 328376 16055620

4. Ошибка в алерте:
ORA-04030: выход за пределы памяти процесса при попытке выделить 8168 байт (callheap,kdbmal allocation)
ORA-04030: выход за пределы памяти процесса при попытке выделить 56 байт (callheap,qesaAllocWrkArea:2)

5. Ограничения для пользователя oracle:
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 16384
oracle hard nproc 16384
oracle soft stack 10240
oracle hard stack 32768
oracle hard memlock 31943040
oracle soft memlock 31943040

6. pfile:

DRIBIN11.__db_cache_size=5419040768
DRIBIN11.__java_pool_size=33554432
DRIBIN11.__large_pool_size=100663296
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','/u01/app/oracle/fast_recovery_area/DRIBIN11/controlfile/o1_mf_cjnsm4oo_.ctl'
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_domain=''
*.db_name='DRIBIN11'
*.db_recovery_file_dest_size=223745146880
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.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'

если на сервере ничего больше нет, в 5м пункте лучше поставить unlimited
проблема не в базе, а в системе

Прошу прощения, забыл добавить, что на сервере работают 2 виртуальные машины 1GB ОЗУ и 1.5GB ОЗУ. KSM не используется. Любые другие операции в СМ2000 (версия 1.033 сп 3) к такой ошибке не приводят. В других базах (менее больших) такой проблемы нет.

т.е. нужно вообще снять ограничения памяти для процессов, я вас правильно понял?

Поставил:

oracle hard memlock unlimited
oracle soft memlock unlimited

Ошибка повторилась....

Поясню ситуацию.
Базе дали 6Гб+, она пытается их использовать.
В системе лимит меньше 6Гб, на который и налетает база. Еще и мусоросборник с виртуалками (очень зря).
Предполагаю, что после unlimited не перезагружался? Он не на ходу меняется...

Перезагружался... или мб я как-то не так меняю? просто правлю /etc/security/limits.conf

мб... перед стартом базы, от того пользователя, под каким база работает, надо выполнить
ulimit -a
будут видны текущие лимиты этого пользователя

базу сейчас не остановить, на текущий момент все выглядит так:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 125934
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 10240
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

/etc/security/limits.d/ надо ещё проверять. если там есть что-то, то оно "главнее" /etc/security/limits.conf
memlock задается в kB. получается 30G

sga_target не вмещается в shared