[ОТВЕТИТЬ]
10.12.2014 18:15
multik
 
Добрый день, уважаемые форумчане.

Помогите пожалуйста, правильно распределить память для oracle.

У меня есть одна маленькая промышленная база oracle 9.2.0.7.
База на виртуальном сервере VmWare
ОС. Win Server 2003 x32
3 процессора 2,4 Ггц
ОЗУ 4Гб
сейчас процесс Oracle занимает 1,3 Гб, смотрю через диспетчер задач

параметры в init.ora :

*.db_block_size=8192
*.db_cache_advice='ON'
*.db_cache_size=1073741824
*.db_file_multiblock_read_count=15
*.db_keep_cache_size=0
*.db_recycle_cache_size=109051904
*.java_pool_size=12582912
*.large_pool_size=12582912
*.pga_aggregate_target=83886080
*.sga_max_size=1077936128
*.shared_pool_size=67108864
*.sort_area_size=524288

подскажите пожалуйста, как мне наиболее оптимально распределить память для серверных процессов и для пользовательских?
Так же возникает проблема с памятью pga. В результате в логе: ORA-04030. я так поняла, что на сервере, процессу oracle можно увеличить память с 1,3 Гб до 3Гб, дописав в boot.ini ключик /3Gb.
Как быть? с чего мне начать?
10.12.2014 19:54
OlegON
 
Добрый день, с одного подхода какие-то рекомендации давать трудно, не зная предназначения БД и, например, текущего количества сессий.
Я бы начал с размышлений на тему перехода на 10 или 11 Oracle, причем, лучше 11, поскольку и 10 уже не поддерживается.

Ключики не спасут, точнее, эту проблему не решат полностью, зато породят другие. Вариантов много, например, переход в сторону shared server (на 9i оно, вроде MTS звалось). Самым правильным будет - переход на 64-битную систему с соответствующей заменой Oracle. Все зависит от потребностей. Можно и просто памяти подрезать, обратите внимание, что в параметрах каша, явно по гайду для 10ки пытались настраивать 9ку. Как минимум workarea_size_policy не назначен, зато pga* воткнули и тут же sort_area_size. Я уже очень смутно помню 9ку, но, насколько память позволяет, стал бы отбрыкиваться от sga_max_size и pga_aggregate_target, вроде бы оно нормально на 10ке только заработало.

В общем, пишите, что мешает поднять версию или подрезать память, а там видно будет.
16.12.2014 16:14
multik
 
К сожалению поднять версию Oracle мы не можем. Много изменений затрагивает смена версии, к которым компания пока не готова. Приходится выкручиваться с тем, что есть(

В БД около 100 сессий, одновременно делают запись в таблицы каждые пол часа + в рабочие часы добавляются пользовательские сессии - чтение.

В топовых событиях, из отчета :
-db file sequential read
-CPU time
-db file scattered read
-log file sync
-buffer busy waits

СОрри, я Вас ввела в заблуждение не указав, что у нас параметр workarea_size_policy = AUTO.
16.12.2014 16:29
OlegON
 
К сожалению, то, что написали, говорит только о том, что железо не справляется с той нагрузкой, которую вы задаете, но у логики приложения есть некоторое алиби. Какую запись, кто они (люди/боты) и могут ли терпеть лаги, вопросов больше, чем ответов... С таким количеством сессий вы всегда будете балансировать выбором между производительностью и вываливанием за пределы памяти процесса. Про MTS что скажете?
16.12.2014 16:51
multik
 
Запись каждые пол часа включаются службы Виндовые, инициируют новые подключения и записывают данные в таблицы. Для них не критична аварийная остановка базы, при доступности БД, они запишут информацию, которую не смогли записать раньше. Критично для реальных пользователей, которые читают эту информацию. Думала еще помониторить, настроила kill сессий с статусом snipped, покрутила настройки в профиле + хочу добавить плановую перезагрузку oraclе. Так же смотрела в сторону MTS. и подумываю перейти.
Просто, не могу понять, почему при переезде базы с одного сервера, с худшими параметрами, на сервер с лучшими параметрами начали возникать ошибки и нехватки памяти, при этом нагрузка осталась прежняя, как до переезда.
16.12.2014 18:13
OlegON
 
Вот видите, задача-то плавает... Всплывают все новые подробности... То задача - увеличить память, то, оказывается, перенести с другого сервера, чтобы не падало :)
Инишник со старого сервера забрали? Как переносили?
16.12.2014 18:34
multik
 
Прошу прощения, видимо хотела, но не написала в теме, что база переехала с железки на виртуалку. Переезд был аварийный, восстанавливала rman'ом из бэкапа, инишник оставила старый, т.к. срочно надо было восстановить. Сейчас хочу параметры привести в порядок, но в настройке производительности oracle - я чайник :(
16.12.2014 18:38
multik
 
сразу хотела просто под доступные ресурсы распределить память для oracle, а затем по возникшим проблемам смотреть и анализировать....
16.12.2014 19:01
OlegON
 
Слова "производительность" и "виртуалка" находятся совсем в разных областях...
Предлагаю вернуть инишник ровно в том же виде, как было. Падать не должно, если раньше не падало. Хотя, на старой ОС /3Gb не прикручивали?
17.12.2014 12:07
bayan
 
Я бы начал с того, что переехал бы на 64 битную ось, всё таки /3Gb оооочень глючная штука.
17.12.2014 12:12
Mtirt
 
А на 64-битную ось удастся поставить 9-ый оракл?
17.12.2014 12:40
bayan
 
объективно не вижу причин пользовать 9i в 2014 году, если уж 10G с поддержки сняли
17.12.2014 12:45
Mtirt
 
ответ автора ветки на это предложение был выше:
Цитата:
multik К сожалению поднять версию Oracle мы не можем. Много изменений затрагивает смена версии, к которым компания пока не готова. Приходится выкручиваться с тем, что есть(

В БД около 100 сессий, одновременно делают запись в таблицы каждые пол часа + в рабочие часы добавляются пользовательские сессии - чтение.

В топовых событиях, из отчета :
-db file sequential read
-CPU time
-db file scattered read
-log file sync
-buffer busy waits

СОрри, я Вас ввела в заблуждение не указав, что у нас параметр workarea_size_policy = AUTO.
23.12.2014 17:26
multik
 
после миграции БД на виртуальный сервер, я собрала системную статистику, т.к. конфигурация сервера изменилась.

Собрала статистику так:

exec SYS.DBMS_STATS.GATHER_SYSTEM_STATS('START'); утром стартанула

exec SYS.DBMS_STATS.GATHER_SYSTEM_STATS('STOP'); вечером остановила. интервал рабочее время

была такая:

SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 06-03-2013 21:38
SYSSTATS_INFO DSTOP 06-03-2013 21:39
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN SREADTIM 8,667
SYSSTATS_MAIN MREADTIM 8,887
SYSSTATS_MAIN CPUSPEED 1196
SYSSTATS_MAIN MBRC 15
SYSSTATS_MAIN MAXTHR 27140096
SYSSTATS_MAIN SLAVETHR -1
23.12.2014 17:30
multik
 
Прошу прощения, случайно в процессе редактирования отправила. Продолжение. Сейчас статистика такая:


Код:
SNAME	PNAME	PVAL1	PVAL2
select * from sys.aux_stats$			
SYSSTATS_INFO	DSTART		11-14-2014 15:46
SYSSTATS_INFO	DSTOP		11-14-2014 15:46
SYSSTATS_INFO	FLAGS	1	
SYSSTATS_MAIN	SREADTIM	4,175	
SYSSTATS_MAIN	MREADTIM	11	
SYSSTATS_MAIN	CPUSPEED	2012	
SYSSTATS_MAIN	MBRC	14	
SYSSTATS_MAIN	MAXTHR	12098560	
SYSSTATS_MAIN	SLAVETHR	-1
23.12.2014 17:42
OlegON
 
Во-первых, системная статистика достаточно косвенная штука к выделению памяти, во-вторых - для версий ниже 10ки я ее отрекомендовываю собирать.
Опции темы


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

 

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