Очень долго выполняется insert в Сличительную ведомость : Oracle

День добрый!

Очень долго выполняется insert на 200000 тысяч позиций

INSERT INTO TTRemains ( StoreLoc, Article, Quantity )( select Location, Article, - SUM(Quantity) Quantity from ( SELECT 13 Location, S.Article, SUM( S.Quantity * DECODE(13,D.LocationTo,1,D.LocationFrom,-1,0)) Quantity FROM SmDocuments D , SmSpec S WHERE D.DocType = S.DocType and D.ID = S.DocID and 13 in (D.LocationTo,D.LocationFrom) and D.DocState >= 2 and D.CreatedAt > to_date('18.11.2012','DD.MM.YYYY') and S.Article in (select Article from SmSpec where DocType='RL' and DocId='СВ0400360') GROUP BY 13, S.Article HAVING SUM( S.Quantity * DECODE(13,D.LocationTo,1,D.LocationFrom,-1,0)) <> 0 UNION ALL SELECT StoreLoc, Article, - Quantity FROM SMGoods WHERE Quantity <> 0 and StoreLoc =13 and Article in (select Article from SmSpec where DocType='RL' and DocId='СВ0400360') ) group by Location, Article having SUM(Quantity) <> 0 )

вот скрин из em

Оракл Version 10.2.0.4.0

Размер базы

25.11.12 19:34:57 -- INDX:11Gb
25.11.12 19:34:58 -- USERS:16Gb
25.11.12 19:34:59 -- SYSAUX:30Gb
25.11.12 19:34:59 -- UNDOTBS1:30Gb
25.11.12 19:35:00 -- SYSTEM:31Gb



OS Name: Microsoft(R) Windows(R) Server 2003, Enterprise Editi
on 32 битная
OS Version: 5.2.3790 Service Pack 2 Build 3790
Original Install Date: 03.10.2009, 1:36:44
System Up Time: 30 Days, 8 Hours, 45 Minutes, 17 Seconds
System Model: ProLiant DL360 G6
System Type: X86-based PC
Processor(s): 4 Processor(s) Installed.

Вчера прогнал оптимайзером сутки Время MT где то часов 6-7 получилось.

оптимайзер ругался только на программу SMUTILS2000

25.11.12 19:36:25 -- SYS YZ PACKAGE BODY 1 1 14 PLS-00201: identifier 'YZ' must be declared ERROR 201
25.11.12 19:36:26 -- SYS YZ PACKAGE BODY 2 1 14 PLS-00304: cannot compile body of 'YZ' without its specification ERROR 304
25.11.12 19:36:26 -- SYS YZ PACKAGE BODY 3 0 0 PL/SQL: Compilation unit analysis terminated ERROR 0

Заранее извиняюсь если что то не успел приложить в качестве информации.
Спасибо!

К сожалению, кроме как размер самой БД мы ничего и не увидели. Хорошо бы весь лог оптимизатора (за один проход с -c=o в МТ и один - без) или хотя бы начать с того, что грузится (винт/проц), если винты, то какие... В общем - лучше лог опта, там все это есть. Глядя на размер SYSAUX, утверждаюсь во мнении, что dbconsole надо стирать сразу, как увидишь... Кстати, за тем, как оно память жрет, тоже бы посмотреть стоило. Было как-то, что всю память эта dbconsole слопала. И "очень долго" это сколько?

Спасибо за ответ! Прикладываю лог с оптимайзера.
Раньше эта сличительная ведомость подбирала остатки за полчаса. Теперь это же не удается сделать и за 7 часов.
это лог опта.
new 2.txt


Судя по графикам em, во время этого процесса сервер особо не напрягается.

кстати такая сличительная но на 200 позиций отработала минут за 5. значит запрос все таки выполняется. проблема всплыла пару дней назад. поддержка сервис плюса предложила использовать свой скрипт который идет в комплекте SM2000Utils. Он называется "Переиндексация и сбор статистики.
Связано ли это с тем что база перезапускалась или с тем что скрипт все таки возымел действие, не понятно, но остатки подбирались очень шустро.

К вечеру проблема возобновлялась. Я решил прогнать базу оптимазером. но получить прежний эффект не удалось. Ни скриптом сервис-плюса ни оптом.
Падение производительности наблюдается и при пересчете ТД. но это не так критично.

Прикладываю еще MT лог

что то в предыдущий лог он не попал
new 2.zip

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

Прикладываю весь алертлог
alert_chizh1.zip

и еще что удалось получить

Блокировки и Ожидания.zip

Надеюсь что поможет.

Ни одного полного отрабатывания оптимизатора в логе... А надо бы.

Прикладываю полный лог опта
optimizer.zip

SQL Tuning Advisor-ом получилось оптимизировать запрос время ожидания уменьшилось на 98 процентов.

но появилось две проблемы.

1. как можно посмотреть код этого "оптимизированного запроса"?

2. при добавлении остатков в разные сличительные ведомости меняется и
SQL ID, что заставляет нас запускать Advisor для каждой ведомости заново.

Вывод.
Как экстренная мера сработало. но хотелось бы более изящного решения.

Для приличия было бы здорово указать в какое время был полный проход. Листать все подряд нет никакого удовольствия.