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

еще раз
select * from v$sgainfo;

переход на что планируешь на выходные????

show parameter sga_target;

[QUOTE=ckadi;112420]alter system set sga_target=1690m;[quote]да, чтобы голову не ломал: ты не указал scope и поскольку стартуешь с spfile - изменения записались в него, но не подейстовали на запущенный экземпляр.

select * from v$parameter where name='sga_target'; -- текущий таргет
select * from v$sgainfo where name='Free SGA Memory Available'; -- свободное место в сга

складываешь и делаешь
alter system set sga_target=чего_получилось scope=memory;
это меняет параметр на действующем экземпляре. работает только до перезапуска.
или
alter system set sga_target=чего_получилось scope=both;
это еще и в spfile

До ключа /3GB примерно 1.4гб озу + 1.5гб свопа oracle.exe занимал в диспетчере задач. Win2k3 же Enterprise - все 8 гб озу видит, pae. Или ограничение х32 винды 1.7гб озу(или озу+своп) на процесс по дефолту? А с ключом /3GB лимит до 3Гб увеличивается? Сделал в boot.ini /PAE /3GB.
Ничего.
Командой alter system set db_cache_size = 100M scope=spfile; задам же минимальный размер Buffer Cache Size?
В базе зачастую максимум клиентов см2к согласно лимиту лицензии.
х64 вин2к3, оракл10й х64 планирую на выходных.
SQL> select * from v$sgainfo;
NAME BYTES RES
Fixed SGA Size 1299820 No
Redo Buffers 7086080 No
Buffer Cache Size 578813952 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 1786773504 No
Startup overhead in Shared Pool 58720256 No
Free SGA Memory Available 8388608
SQL> show parameter sga_target;
NAME TYPE VALUE
sga_target big integer 1696M
Это после ребутов, 20-00 +-, т.е. база почти без клиентов (2-4).
Храмова прокачал, он стал готов платить 500р за 30дней регеного оптимизатора, осталось готовность в действие преобразовать.
В целом поведение базы в плане тормозов и очень долгого расчета себестоимости напоминает случай с подчиненной базой до НГ: считали себестоимость, тыкнули отменить, не дождались отмены, тыкнули резет физически, на той базе оптимизатор использовался раз в 30мин не регеный, в итоге за место согласится на помощь Олегона тупо сменил железо+оракл10й с пустой базой, проинициализировал с ЦО (приказ руководства был так сделать).
Сегодня Victoria утилитку использовал, смарт статус винтов нормальный, а скорость чтения 2х винтов была 10`000кб\с, 2х 100`000кб\с. Вечером переткнул 2 винта с сата3 на сата2 разъемы, скорость чтения 130`000-160`000кб\с стала.

если это не ошибка в единицах, то страшное дело - как оно вообще шевелится

130`000 kb\s точнее
set db_cache_size = 100M scope=both; выполнил, перезапуск службы базы, после этого перенос(после "только расчеты" очистки аналитической бд) 55 секунд длился (предыдущий после полной очистки аналитич. БД за 22часа до этого был выполнен), а расчет длился 20минут28секунд. Не плохо:)

Утром обратились, что отчет "Доходность по товарам" за 28.03.2012 пустой результат выдает. Полную очистку аналитической БД, перенос(25,5мин),расчет(21мин) выполнил - нормальную инфу отчет за 28е показал.

неформатированный поток сознания. :)

что значит ничего? ты поднял sga до 1.7 и прирезал 500М плюсом к буферам. это ничего?
Buffer Cache Size 58 720 256 - было
Buffer Cache Size 578 813 952 - стало
почувствуй разницу. у меня база ЦО вставала колом, когда буфера падали до 300М

или ты от /pae чего-то ожидал? не дождешься. сам по себе он ничего не дает. :)
все равно прямо адресуемой памяти будет только 2.7 на процесс в х32, хоть убейся.

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

alter system set db_cache_size = ... физического смысла не имеет, пока sga_target не равен нулю.
ненулевой таргет подразумевает автоматическое управление памятью. оракл все равно будет отгрызать куски от кэша буферов, если они нужны куда-то еще.

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

Здравствуйте, столкнулись с такой ситуацией:
расчет себестоимости начал занимать огромное время, если раньше было 3-4 часа то сейчас около 9-12 часов.
что имеем:
сервер базы данных Oracle 10 :E5620 2.40 GHz, 10Gb
сервер приложения: Xeon 2.8GHz, 2Gb

раньше считалось и запускалось на сервере базы, сейчас запускается по расписанию в админке и я так понимаю считается все на сервере СМ.

Если запускаю ручками перенос и расчет в админском модуле на сервере базы, то он считается за 3 часа но падает в ошибку на моменте сохранения расчета в базу.

Вот текст ошибки:

SQL*Loader: Release 10.2.0.4.0 - Production on Tue Jul 31 05:23:33 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

SQL*Loader-704: Internal error: ulconnect: OCIServerAttach [0]
ORA-12154: TNS:could not resolve the connect identifier specified


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

в текущей конфигурации, наверное, никак. т.е. сервер СМ придется поставить на нормальную машинку или привести в самочувствие ту, которая до этого работала нормально, либо сетку между ними. предполагаю установку антивируса или еще какую-то помойку.

сеть между ними гигабитная, антивируса нет, но они в домене

сейчас можно гадать сколько угодно, но если с одного хоста считается быстро, то дело не в БД. соответственно, раз раньше работало, то что-то поменяли. вот это поменяное и надо вернуть обратно :) засеки просто конкретное время выполнения конкретных шагов на разных хостах. заливка, которая у тебя идет с обрывом TNS, часто занимает очень даже значительное время.