[ОТВЕТИТЬ]
Опции темы
15.04.2016 10:17
 
Столкнулся с вышеуказанной проблемой. Проблема появляется, только в рабочее время, когда работают все пользователи 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'
15.04.2016 10:18
 
если на сервере ничего больше нет, в 5м пункте лучше поставить unlimited
проблема не в базе, а в системе
15.04.2016 10:28
 
Прошу прощения, забыл добавить, что на сервере работают 2 виртуальные машины 1GB ОЗУ и 1.5GB ОЗУ. KSM не используется. Любые другие операции в СМ2000 (версия 1.033 сп 3) к такой ошибке не приводят. В других базах (менее больших) такой проблемы нет.
15.04.2016 10:29
 
Цитата:
Inima если на сервере ничего больше нет, в 5м пункте лучше поставить unlimited
проблема не в базе, а в системе
т.е. нужно вообще снять ограничения памяти для процессов, я вас правильно понял?
15.04.2016 11:48
 
Поставил:

oracle hard memlock unlimited
oracle soft memlock unlimited

Ошибка повторилась....
15.04.2016 11:53
 
Поясню ситуацию.
Базе дали 6Гб+, она пытается их использовать.
В системе лимит меньше 6Гб, на который и налетает база. Еще и мусоросборник с виртуалками (очень зря).
Предполагаю, что после unlimited не перезагружался? Он не на ходу меняется...
15.04.2016 11:59
 
Цитата:
OlegON Поясню ситуацию.
Базе дали 6Гб+, она пытается их использовать.
В системе лимит меньше 6Гб, на который и налетает база. Еще и мусоросборник с виртуалками (очень зря).
Предполагаю, что после unlimited не перезагружался? Он не на ходу меняется...
Перезагружался... или мб я как-то не так меняю? просто правлю /etc/security/limits.conf
15.04.2016 12:49
 
мб... перед стартом базы, от того пользователя, под каким база работает, надо выполнить
ulimit -a
будут видны текущие лимиты этого пользователя
15.04.2016 12:55
 
базу сейчас не остановить, на текущий момент все выглядит так:
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
15.04.2016 13:05
 
/etc/security/limits.d/ надо ещё проверять. если там есть что-то, то оно "главнее" /etc/security/limits.conf
memlock задается в kB. получается 30G

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


Опции темы



Часовой пояс GMT +3, время: 22:33.

Все в прочитанное - Донат - RSS - - Карта - Вверх

Форум сделан на основе vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.