[ОТВЕТИТЬ]
Опции темы
26.11.2012 19:42  
omnomnom
День добрый!

Очень долго выполняется 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 Нажмите на изображение для увеличения
Название: O7JUU.png
Просмотров: 397
Размер:	119.5 Кб
ID:	1458

Оракл 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


Заранее извиняюсь если что то не успел приложить в качестве информации.
Спасибо!
 
26.11.2012 20:01  
OlegON
К сожалению, кроме как размер самой БД мы ничего и не увидели. Хорошо бы весь лог оптимизатора (за один проход с -c=o в МТ и один - без) или хотя бы начать с того, что грузится (винт/проц), если винты, то какие... В общем - лучше лог опта, там все это есть. Глядя на размер SYSAUX, утверждаюсь во мнении, что dbconsole надо стирать сразу, как увидишь... Кстати, за тем, как оно память жрет, тоже бы посмотреть стоило. Было как-то, что всю память эта dbconsole слопала. И "очень долго" это сколько?
 
26.11.2012 21:32  
omnomnom
Спасибо за ответ! Прикладываю лог с оптимайзера.
Раньше эта сличительная ведомость подбирала остатки за полчаса. Теперь это же не удается сделать и за 7 часов.
это лог опта.
new 2.txt


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

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

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

что то в предыдущий лог он не попал
new 2.zip
 
26.11.2012 22:28  
OlegON
Уже поздновато, не посмотрю сейчас, но что если поставить оптимизатор на регулярную основу? Есть еще повод попробовать изменить значение BrokenCBO или как его там параметр оптимизатора. Но я бы не менял, а просто впилил бы на раз в полчаса, чтобы ходил...
 
27.11.2012 02:14  
omnomnom
Прикладываю весь алертлог
alert_chizh1.zip

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

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

Надеюсь что поможет.
 
27.11.2012 08:12  
OlegON
Ни одного полного отрабатывания оптимизатора в логе... А надо бы.
 
27.11.2012 09:47  
omnomnom
Прикладываю полный лог опта
optimizer.zip
 
27.11.2012 14:27  
omnomnom
SQL Tuning Advisor-ом получилось оптимизировать запрос время ожидания уменьшилось на 98 процентов.

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

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

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

Вывод.
Как экстренная мера сработало. но хотелось бы более изящного решения.
 
27.11.2012 17:04  
OlegON
Цитата:
Сообщение от omnomnom
Прикладываю полный лог опта
Вложение 1463
Для приличия было бы здорово указать в какое время был полный проход. Листать все подряд нет никакого удовольствия.
 
 


Опции темы



Часовой пояс GMT +3, время: 18:26.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.