Добрый день!
Прошу профессионального совета, и профессиональной оценки состояния.
Что имеем:
- Oracle 9i Enterprise 32 b
- большая база данных (>300Gb)
- сервер WinServer 2003 EE
- ОЗУ - 64 Gb
- процессоров - 8
- HDD - база лежит на 6 дисках по 400 Gb (сделаны из 10 RAID)
- количество пользователей - 1000+
- тип пользователей - собственный приложения, веб-приложения, линки на иные БД.
- есть несколько табличных пространств, где размещаются разделы отдельных приложений(размещены на разных дисках);
- есть несколько пользователей, которые работают каждый со своими правами;
- SGA (SharedPool=320,BufferCache=456,LargePool=8) PGA =500
Проблема:
1. когда работает малое число пользователей, то все хорошо летает, быстро отрабатывают запросы, строятся отчета, которые анализируют данные.
2. Когда одновременно работающих пользователей подходит к 500 и выше, то сразу появляются заметные "тормоза", подвисают переходы между полями (т.к при переходе идет обращение к БД). долго выполняются запросы, особенно сложные запросы.

Много чего оптимизировали как в программе так и в структуре данных, упрощали, улучшали, работать становится действительно быстрее, но при большом числе пользователей все также начинает "подтормаживать" и даже бывает что Оракл в принципе перестает работать, что его приходится перезагружать.

Вопросы:
1. Возможно ли администрировать/настраивать СУБД таким образом, что отдельные табличные пространства/пользователи работали медленно, а отдельные быстро?
2. При такой конфигурации какой предел пользователей с адекватной работой программ?
3. какие дальнейшие пути решения? дальше оптимзировать ПО, структуру БД и запросы к БД, либо переходить на иную версию и разрядность СУБД?

Спасибо,
Еще раз прошу прокомментировать по существу.

Dimitry Sibiryakov,
дело в том, что системный администратор есть который умеет/ говорит что умеет...но как то все равно быстрее не становится, а задача ускорить процесс - есть и причем большая, т.к. число пользователей увеличится в 2 раза минимум и что делать тогда?

Vadim Lejnin,

правильно я понимаю, что даже при больших объемах данных, которые выбираются пользователями в такой конфигурации должно работать нормально?
меня беспокоит вопрос увеличения числа пользователей, если на эту схему число пользователей увеличиться в два раза как оно будет работать?


будет ли прирост если мы перейдем на 64 разрядную БД, без изменения структуры данных? заметят ли это пользователи или нет?

спасибо

Вячеслав ЛюбомудровОбъем-то как раз небольшой, вот кол-во юзеров большое для такой платформы. Еще бы узнать, сколько из-них одновременно активны.
Можно заюзать Shared servers (aka MTS), чтоб уменьшить PGA для такого количества юзеров, но в 9-ке надо не забывать, что тогда придется использовать [SORT|HASH]_AREA_SIZE вместо PGA_AGGREGATE_TARGET (может и к лучшему)
Обязательно, как уже сказали, /3GB в boot.ini
Про AWE вопрос спорный

ЗЫ. PGA=500, подозреваю, что речь идет про PGA_AGGREGATE_TARGET, но она ограничивает (точнее, только старается) только области сортировки/хеширования, но никак не всю PGA

спасибо!
поясните по Вячеслав ЛюбомудровОбязательно, как уже сказали, /3GB в boot.ini"
ОС 2003 Server Enterprise Edition, и сама ОС видит все 64 Гб,
правильно ли я помниаю что /3GB даст возможность Oracle использовать больше памяти?

dba123HANK,

Показал бы сразу как считаешь пользователей(1000+), PGA и
сколько памяти занимает процесс oracle.exe (например, в диспетчере задач)



сегодня
SERVER COUNT(*)
DEDICATED 1016

Памяти Oracle занимает под 2 ГБ

Vadim Lejnin,
у нас есть кто этим занимается, и даже собирал эту аналитику, дело в том, что когда мы беседуем про развитие СУБД, то просто все сводится к следующему:
- так "криво" организованы данные и написаны программы, что не удивительно что так оно медленно работает, и все занимаемся просто напросто оптимизацией программ, структур данных и т.д., и вроде оно становится лучше, но потом когда вырастает нагрузка все также замедляется.
(словно администратор вводит в заблуждение (он тоже кстати пишет это ПО, и оно также "тормозит", не желает видеть реальных проблем СУБД , и сваливает все на ПО, вместо того чтобы перейти на более современную архитектуру).
к примеру, когда я общаюсь с иными пользователями СУБД Оракл, у которых есть решением на нем, так они говорят о том, что вообще не занимаются настройкой БД, все работает по дефолту и заглушек нет, но там версия имеет возможность использования больше ОЗУ и запросов там так же огромное множество)
меня самого удивляет количество ОЗУ, которое затребовал администратор СУБД, но очевидно что при таком подходе эта ОЗУ попросту не используется, по некоторым ощущениям в таком случае мы компьютером забиваем гвозди...
хотел услышать стороннее мнение экспертов СУБД по этому поводу, а именно
есть ли все таки предел у такой конфигурации, и что обязательно переход на другую версию ORACLE или этой конфигурации достаточно, и можно еще лет 5-10 работать без проблем, и действительно нужно смотреть в сторону того как написаны программы и как организованы данные.
последняя идея меня не очень устраивает, т.к. такая бесконечная оптимизация с моей точки зрения просто дает возможность продлить работу данной СУБД (без кардинального ее изменения).
объемы данные очень большие это миллионные таблицы, в которые постоянно что-то дописывается и ищется, это взаимодействие между таблицами внутри, куча выборок, которые постоянно запрашиваются пользователями(при работе в ПО).
и Мне хочется услышать также кардинального совета на будущее, чтобы система функционировала быстро и без проблем.

S_e_r_j,

у меня его нет..в том то и дело, у меня есть только слова администратора..

былоHANKу меня его нет..в том то и дело, у меня есть только слова администратора..
Тебе уже сказали - единственное что тебе может помочь, если оставаться на 32разрядной 9ке при таком количестве пользователей это:

тынц раз :
Вячеслав ЛюбомудровОбъем-то как раз небольшой, вот кол-во юзеров большое для такой платформы. Еще бы узнать, сколько из-них одновременно активны.Можно заюзать Shared servers (aka MTS)

тынц два :
а_так?пустить 500 пользователей через shared_servers уже предлагали ?

/3GB ключ используется.
пользователей не меньше 700 работает всегда, в пике за 1000

спасибо всем за советы!