Как правильно увеличить память для oracle : Oracle

Добрый день, уважаемые форумчане.

Помогите пожалуйста, правильно распределить память для 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 или 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ке только заработало.

В общем, пишите, что мешает поднять версию или подрезать память, а там видно будет.

К сожалению поднять версию Oracle мы не можем. Много изменений затрагивает смена версии, к которым компания пока не готова. Приходится выкручиваться с тем, что есть(

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

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

СОрри, я Вас ввела в заблуждение не указав, что у нас параметр workarea_size_policy = AUTO.

К сожалению, то, что написали, говорит только о том, что железо не справляется с той нагрузкой, которую вы задаете, но у логики приложения есть некоторое алиби. Какую запись, кто они (люди/боты) и могут ли терпеть лаги, вопросов больше, чем ответов... С таким количеством сессий вы всегда будете балансировать выбором между производительностью и вываливанием за пределы памяти процесса. Про MTS что скажете?

Запись каждые пол часа включаются службы Виндовые, инициируют новые подключения и записывают данные в таблицы. Для них не критична аварийная остановка базы, при доступности БД, они запишут информацию, которую не смогли записать раньше. Критично для реальных пользователей, которые читают эту информацию. Думала еще помониторить, настроила kill сессий с статусом snipped, покрутила настройки в профиле + хочу добавить плановую перезагрузку oraclе. Так же смотрела в сторону MTS. и подумываю перейти.
Просто, не могу понять, почему при переезде базы с одного сервера, с худшими параметрами, на сервер с лучшими параметрами начали возникать ошибки и нехватки памяти, при этом нагрузка осталась прежняя, как до переезда.

Вот видите, задача-то плавает... Всплывают все новые подробности... То задача - увеличить память, то, оказывается, перенести с другого сервера, чтобы не падало :)
Инишник со старого сервера забрали? Как переносили?

Прошу прощения, видимо хотела, но не написала в теме, что база переехала с железки на виртуалку. Переезд был аварийный, восстанавливала rman'ом из бэкапа, инишник оставила старый, т.к. срочно надо было восстановить. Сейчас хочу параметры привести в порядок, но в настройке производительности oracle - я чайник :(

сразу хотела просто под доступные ресурсы распределить память для oracle, а затем по возникшим проблемам смотреть и анализировать....

Слова "производительность" и "виртуалка" находятся совсем в разных областях...
Предлагаю вернуть инишник ровно в том же виде, как было. Падать не должно, если раньше не падало. Хотя, на старой ОС /3Gb не прикручивали?

Я бы начал с того, что переехал бы на 64 битную ось, всё таки /3Gb оооочень глючная штука.