расчет себестоимости стал медленным : Супермаг Плюс (Супермаг 2000)

в любом случае, тормоз - не болячка. биться за скорость до обновления не стоит. только если память поправить из самых общих соображений.

1) проверить валидность базы.
2) проверить выделение памяти
3) обновиться
4) разбираться со скоростью

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

SQL> select * from v$pgastat;
NAME VALUE UNIT
---------------------------------------------------------------- ---------- ------------
aggregate PGA target parameter 418381824 bytes
aggregate PGA auto target 313003008 bytes
global memory bound 83676160 bytes
total PGA inuse 75076608 bytes
total PGA allocated 104047616 bytes
maximum PGA allocated 495371264 bytes
total freeable PGA memory 0 bytes
process count 65
max processes count 77
PGA memory freed back to OS 0 bytes
total PGA used for auto workareas 4431872 bytes
maximum PGA used for auto workareas 109241344 bytes
total PGA used for manual workareas 0 bytes
maximum PGA used for manual workareas 82751488 bytes
over allocation count 0
bytes processed 3,1942E+10 bytes
extra bytes read/written 2328931328 bytes
cache hit percentage 93,2 percent
recompute count (total) 15223
19 строк выбрано.

SQL> select * from v$sgainfo;
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1298280 No
Redo Buffers 7090176 No
Buffer Cache Size 58720256 Yes
Shared Pool Size 1174405120 Yes
Large Pool Size 8388608 Yes
Java Pool Size 8388608 Yes
Streams Pool Size 0 Yes
Granule Size 8388608 No
Maximum SGA Size 1258291200 No
Startup overhead in Shared Pool 50331648 No
Free SGA Memory Available 0
11 строк выбрано.
Незарегистрированный оптимайзер с месяц назад запускался с интервалом 30мин, отработать у него получалось пару раз в сутки максимум. Платить за регистрацию не хочет руководство, поэтому имею что имею.

Buffer Cache Size 58 720 256 Yes
странно, что она вообще шевелится. 58 метров в буферах, остальное с диска.

1) = сделать "эталон" в подчиненной заведомо рабочей\... и сравнить с эталоном в ЦО?

секционирование FFMAPREP выключал? если нет, то имей в виду, что оптер секции на два месяца вперед только делает. если вовремя не запустить хоть один раз в MT - первого числа рассчет ТД встанет по ошибке на загрузке.

не трогал, практически с дефолтными настройками оптимайзер был, архивлог выкл

SGA size 125мб+- - может его увеличить? Такое видел: alter system set sga_target = <размер в байтах(?)>;
buffer caсhe как увеличить?

Сравнил с эталоном(подчиненная бд) структуру бд в адм.модуле: Чего то совсем грустно.

в параметрах оптера проверь DontUseFFMAPREP. если там "no". то или ffmaprep обратно из партиций собирать, или делать новые руками или иногда оптера все-таки запускать.

Maximum SGA Size 1 258 291 200
из них
Shared Pool Size 1 174 405 120
Buffer Cache Size 58 720 256

автомат распределения памяти имеет дурную привычку не возвращать то, что он однажды забрал под Shared Pool

maximum PGA allocated 495 371 264 - нафига ему столько понадобилось, я понять не могу, но меньше ты ему дать не можешь.

совсем грубо:
1 258 291 200 - sga
495 371 264
300 000 000 - условно на прочие внутренние нужды экземпляра

подобрались к 2G. я так понимаю, /3GB в boot.ini включен?

Да вроде ничего катастрофичного не видать.
Все нежно и аккуратно можно привести в соответствие. Только пошагово и с бэкапами.

Сначала все-таки
alter system set sga_max_size=XXXX scope spfile;
с предварительным бэкапом и последующим рестартом базы.

но вот этот самый XXXX сначала надо тщательно просчитать. чтобы не вылезать за 2.7G на виндовый процесс с учетом того, что PGA ты сверху ограничить не можешь: если он захочет расти и не сможет - экземпляр грохнется. но так или иначе, метров 500 ты запросто можешь прирезать дополнительных.

а потом можно уже на ходу разбираться с sga_target, он динамический.

если захочется вылезти за 2.7 - тогда сложнее. или включать AWE или перебираться на x64 или вообще переезжать на линукс. я свой офис, как временный вариант, перевел на AWE и прирезал 3.5Г буферов через окно 700М. пока все счастливы.

В boot.ini /3GB не было ключа. Сейчас добавил, вечером, когда база практически не будет использоваться ребутнусь, гляну результат. Oracle.exe чуть меньше 1.3гб озу использует и 1.4гб свопа сейчас.

sga_max_size как высчитывается таки? 2,7GB озу на процесс, вычесть PGA неконтролируемые по макс размеру, допустим ХХХХ=600мб сделать норм или и больше можно, 1-1.5гб?