ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
15 сообщений из 15, страница 1 из 1
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39106445
PSD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PSD
Участник
База DB2
Есть запрос который должен считать количество карточек НЗ и средне время исполнения НЗ.
Запрос выполняется порядка 8 минут если у брать убрать условие WS_con.status ='CONTR' запрос исполняется за 3,5 секунды.
Что странно аналогичное условие по этой же таблице уже есть WS.status ='COMP' и его наличие на производительность никак не влияет.
Помоги разобраться.




Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
select col1,col2,col3 ,col4,count (*) col5
, avg(TIMESTAMPDIFF( 2,CHAR(timestamp ( changedate )- timestamp ( PMDUEDATE )))/3600.0 )COL6 
from 
(select col1,col2,col3 ,col4, PMDUEDATE, max(changedate) changedate
from (
select  L_PG.DESCRIPTION COL1, L_MR.SHORTPATH COL2, CG.DESCRIPTION COL3 , CS.DESCRIPTION COL4,  pm.PMDUEDATE, ws_con.changedate

from   maximo.WOSTATUS WS
left join maximo.WORKORDER PM on  WS.WONUM=PM.WONUM
left join maximo.COMMODITIES CG on  PM.COMMODITYGROUP  = CG.COMMODITY
left join  maximo.COMMODITIES CS on PM.COMMODITY = CS.COMMODITY  
left join maximo.LOCATIONS L_PG on PM.PRED = L_PG.LOCATION  
left join maximo.LOCATIONS L_MR on cs.PODRM=L_MR.LOCATION   
left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM

where  WS.status ='COMP' and  WS.CHANGEDATE between  '2015-09-01' and '2015-11-01'
and  WS_con.status ='CONTR'
and pm.PMNUM is not null 
and pm.MONTHPLAN is not null
and L_MR.SHORTPATH like 'ПСПП/МУ/МГВП/%'  ) f
group by  col1,col2,col3 ,col4,PMDUEDATE) ff
group by  col1,col2,col3 ,col4
...
Рейтинг: 0 / 0
18.11.2015, 12:21
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39106514
Добрый Э - Эх
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Добрый Э - Эх
Гость
PSD,

в вопросах производительности запросов всегда нужно начинать с просмотра их планов выполнения.
...
Рейтинг: 0 / 0
18.11.2015, 12:58
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39106715
m&n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m&n
Гость
PSD,

На 8.2 и на 9.1 сталкивался с какой-то "фигней" при использовании сравнения varchar полей, допускающих NULL.
В общем, запрос со сравнением вида
Код: sql
1.
ucase(WS_con.status) ='CONTR'

работал быстрее,
чем запрос с условием вида
Код: sql
1.
WS_con.status ='CONTR'

.

P.S. вместо ucase м.б. другая подходящая по смыслу строковая функция.
...
Рейтинг: 0 / 0
18.11.2015, 14:52
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39106782
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Вещей вроде ""Cost Based Oracle Fundamentals" by Jonathan Lewis" "у нас" нет, это довольно обидно, но почитайте хотя бы её.

Ленивый вариант - натравите на свой запрос db2advis, он может что-нибудь полезное насоветовать. Я обычно так оптимизирую ;-).

Я предполагаю также, что статистика runstats with distribution and detailed indexes all у вас собрана. Может, при этом количество частот и квантилей имеет смысл поднять.

Возможный механизм проблемы: добавление дополнительного условия резко снижает оценку, начинает использоваться loop join по индексу вместо предыдущего hash join фуллсканом то таблице или индексу, тогда как оценка резко не совпадает с действительностью и нужен именно hash join.

Надо сравнивать планы, оценки, реальные количества в узлах, прикинуть, не нужна ли многоколоночная статистика.
...
Рейтинг: 0 / 0
18.11.2015, 15:17
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39106817
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
PSD,

Условием WS_con.status ='CONTR' вы заставляете db2 обращаться к:
left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM
а условием WS.status ='COMP' - к:
from maximo.WOSTATUS WS

Таблица-то та же, только в первом случае вы заставляете 2-й раз к ней обращаться. Без условия на WS_con.status оно может даже 2-й раз вообще не обращаться к этой таблице (как будто этого left join вообще нет).
...
Рейтинг: 0 / 0
18.11.2015, 15:33
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107028
PSD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PSD
Участник
авторУсловием WS_con.status ='CONTR' вы заставляете db2 обращаться к:
left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM
а условием WS.status ='COMP' - к:
from maximo.WOSTATUS WS

Таблица-то та же, только в первом случае вы заставляете 2-й раз к ней обращаться. Без условия на WS_con.status оно может даже 2-й раз вообще не обращаться к этой таблице (как будто этого left join вообще нет).

Вы имеете ввиду что WS.status ='COMP' порождает пробег по произведению таблиц PM и WOSTATUS ?

Что вы посоветуете сделать в данном случае?

Пробовал заменить left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM на
left join (select * from maximo.WOSTATUS where maximo.WOSTATUS.status ='CONTR') WS_con on WS_con.WONUM=PM.WONUM

Результат тот же.
...
Рейтинг: 0 / 0
18.11.2015, 17:34
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107089
Добрый Э - Эх
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Добрый Э - Эх
Гость
PSD,

непонятно вообще, для чего ты используешь там половину LEFT JOIN-ов, если всё одно в WHERE срезаешь результат внешнего соединения до банального INNER JOIN...

вот смотри на WHERE:

1) and pm.PMNUM is not null and pm.MONTHPLAN is not null срезают left join maximo.WORKORDER PM on WS.WONUM=PM.WONUM до INNER-а

2) and L_MR.SHORTPATH like 'ПСПП/МУ/МГВП/%' срезает left join maximo.LOCATIONS L_MR on cs.PODRM=L_MR.LOCATION до INNER-а

3) and WS_con.status ='CONTR' срезает left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM до INNER-а


Так зачем усложнять жизнь серверу и требовать от него OUTER-соединения?
...
Рейтинг: 0 / 0
18.11.2015, 18:18
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107092
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
PSD,

Дело не в этом.
Вы можете объяснить, почему вы делаете так:

from maximo.WOSTATUS WS
left join maximo.WORKORDER PM on WS.WONUM=PM.WONUM
left join maximo.COMMODITIES CG on PM.COMMODITYGROUP = CG.COMMODITY
left join maximo.COMMODITIES CS on PM.COMMODITY = CS.COMMODITY
left join maximo.LOCATIONS L_PG on PM.PRED = L_PG.LOCATION
left join maximo.LOCATIONS L_MR on cs.PODRM=L_MR.LOCATION
left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM
where WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01'
and WS_con.status ='CONTR' ...

а не так:

from maximo.WOSTATUS WS
left join maximo.WORKORDER PM on WS.WONUM=PM.WONUM
left join maximo.COMMODITIES CG on PM.COMMODITYGROUP = CG.COMMODITY
left join maximo.COMMODITIES CS on PM.COMMODITY = CS.COMMODITY
left join maximo.LOCATIONS L_PG on PM.PRED = L_PG.LOCATION
left join maximo.LOCATIONS L_MR on cs.PODRM=L_MR.LOCATION
where WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01'
and WS.status ='CONTR' ...

Т.е. зачем вы вообще второй раз к этой таблице обращаетесь по другому корр. имени?
...
Рейтинг: 0 / 0
18.11.2015, 18:21
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107100
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Тут, наверное, надо логику хранения и извлечения данных понимать.
Т.е. что именно вы хотите этим запросом возвратить, какой смысл этого поля maximo.WOSTATUS.WONUM (оно уникальное или нет, или пара WONUM, STATUS уникальная, если нет - покажите хоть пример того, что там в этих таблицах вообще хранится, как они связаны между собой).
...
Рейтинг: 0 / 0
18.11.2015, 18:30
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107653
PSD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PSD
Участник
Mark Barinstein,

Код: sql
1.
2.
WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01'
and WS.status ='CONTR'



Такой вариант не пойдет , WS.status не может быть одновременно и 'COMP' и 'CONTR'
...
Рейтинг: 0 / 0
19.11.2015, 13:00
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107741
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
PSDТакой вариант не пойдет , WS.status не может быть одновременно и 'COMP' и 'CONTR'Это да, я ошибся.

Вы должны понять, что с этим дополнительным условием это просто 2 разных запроса.
Сравните результат этого запроса, и запроса с раскомментированными строками.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
with WOSTATUS (WONUM,  status, CHANGEDATE) as (values 
  (1, 'CONTR', '2099-09-01')
, (1, 'CONTR', '2099-09-02')
, (1, 'COMP', '2015-09-03')
)
SELECT 
  WS.*
--, WS_contr.*
FROM WOSTATUS WS
--LEFT JOIN WOSTATUS WS_contr ON WS.WONUM=WS_contr.WONUM
WHERE WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01'
--and WS_contr.status ='CONTR'
;



Во втором случае оптимизатору по каждой найденной записи в WOSTATUS с условием
WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01'
надо будет еще раз залезть в ту же таблицу, чтобы узнать, а есть ли по этому же WONUM еще записи с другим STATUS.
Гораздо больше работы надо сделать...
...
Рейтинг: 0 / 0
19.11.2015, 13:56
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107824
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
У меня нет желания вникать в таким образом написанный и отформатированный запрос на непонятных данных, но выскажусь всё равно ;-).

Как может добавление условия затормозить запрос? Вот один из сценариев:

Положим, у нас есть таблица T1 с C1 (cardinality) записей.
Предикат P11 оставляет в выборке S11*C1 записей, то есть
SELECT count(*) FROM T1 WHERE P11 возвращает S11*C1.

(S11 - это дробное число между 0 и 1, selectivity)

Аналогично,
Предикат P12 оставляет S12*C1 записей
SELECT count(*) FROM T1 WHERE P12 возвращает S12*C1.

Сколько будет
SELECT count(*) FROM T1 WHERE P11 AND P12?
Да сколько угодно в некоторых пределах - от нуля до минимума между S11*C1 и S12*C1, то есть цифра могла вообще не поменяться. Но если, положим, оптимизатор правильно оценивает селективность как S11 и S12, то без мультиколоночной статистики он возьмёт число S11*S12.

Теперь, чем это грозит.

был
SELECT ...
FROM T1 JOIN T2 ON ...
WHERE P1

стал
SELECT ...
FROM T1 JOIN T2 ON ...
WHERE P1 AND P2

и положим, что при выполнении соединения "внешняя" таблица T1, а "внутренняя" T2. Самыми распространёнными путями доступа к данным джойна являются NLJOIN и HASH JOIN. NLJOIN "обычно" идёт по индексу, и хорошо это тогда, когда записей от T1 в цикле участвует очень-очень "мало" - в противном случае море одноблочных обращений приводит к тормозам. Доступ по хешу гораздо более годится, когда от T1 участвует "много" записей.

И если добавление предиката P2 привело к заниженной оценке, и оттого правильный в данной ситуации HASH JOIN сменился на NLJOIN, потому что оптимизатор посчитал, что строк будет много меньше, чем оказалось на самом деле, начались тормоза.

К запросу топикстартера это может иметь отношение, а может не иметь, но планы-таки надо анализировать.

Одна из вещей, которыми меня огорчает DB2 в данном аспекте, это что actuals идут за дополнительную плату (Workload Management), то есть в Express-C их не увидеть. И counts надо будет считать вручную, примерно как мы видим в старых статьях на developerworks.
...
Рейтинг: 0 / 0
19.11.2015, 15:03
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39107911
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Victor MetelitsaОдна из вещей, которыми меня огорчает DB2 в данном аспекте, это что actuals идут за дополнительную плату (Workload Management), то есть в Express-C их не увидеть. И counts надо будет считать вручную, примерно как мы видим в старых статьях на developerworks.
Виктор,

Возможность получения section actuals никах не связана с WLM. Я не пробовал именно с Express-C, но оно там должно быть доступно.
Вам разрешено пользоваться WLM функциями, например, такими как WLM_SET_CONN_ENV. Пока вы не создаете объектов WLM (event monitor for activities к ним не относится).

 
У вас что, не работает на Express-C что-то из этого:

- CREATE EVENT MONITOR ACT FOR ACTIVITIES ...

- Включение сбора для своего (или для другого, если handle известен) соединения
CALL WLM_SET_CONN_ENV(NULL,
'<collectactdata>WITH DETAILS, SECTION</collectactdata><collectsectionactuals>BASE</collectsectionactuals>'
);

- query ...

- Выключение
CALL WLM_SET_CONN_ENV(NULL,
'<collectactdata>NONE</collectactdata><collectsectionactuals>NONE</collectsectionactuals>'
);

- Поиск запроса в таблицах, нахождение параметров для процедуры, заполнение explain таблиц
CALL EXPLAIN_FROM_ACTIVITY ...

- форматирование
db2exfmt
...
Рейтинг: 0 / 0
19.11.2015, 16:03
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39108107
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Спасибо. Я был настолько уверен, что не удосужился проверить (причём не раз обжигался). То есть, я что-то такое уже проверял, оно не работало, жалуясь на лицензионные ограничения, и я бросил это дело. А вот это, похоже, работает. Ну, тем лучше.
...
Рейтинг: 0 / 0
19.11.2015, 18:12
| Ответить | Цитировать | Написать  
Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
    #39109115
PSD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PSD
Участник
Mark BarinsteinPSDТакой вариант не пойдет , WS.status не может быть одновременно и 'COMP' и 'CONTR'Это да, я ошибся.



Но мысль была правильная, я добавлял второй join потому что для дальнейших вычислений мне гораздо удобней иметь все необходимые данные в одной записи, но так как запись которая выбирается по условию WS.status ='COMP' and WS.CHANGEDATE between '2015-09-01' and '2015-11-01' в дальнейших вычислениях не участвует (она нужна только для того чтобы найти в WORKORDER нужные записи) то действительно можно получать все данные через один join а затем перед агрегацией отфильтровать. в итоге получился следующий запрос с временем исполнения 2,3 секунды.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
select col1,col2,col3 ,col4,count (*) col5
, avg(TIMESTAMPDIFF( 2,CHAR(timestamp ( changedate )- timestamp ( PMDUEDATE )))/3600.0 )COL6 
from 
(select WONUM, col1,col2,col3 ,col4, PMDUEDATE, max(changedate) changedate 
from (
select  PM.WONUM, L_PG.DESCRIPTION COL1, L_MR.SHORTPATH COL2, CG.DESCRIPTION COL3 , CS.DESCRIPTION COL4,  pm.PMDUEDATE, ws.changedate, WS.status

from   maximo.WOSTATUS WS
left join maximo.WORKORDER PM on  WS.WONUM=PM.WONUM
left join maximo.COMMODITIES CG on  PM.COMMODITYGROUP  = CG.COMMODITY
left join  maximo.COMMODITIES CS on PM.COMMODITY = CS.COMMODITY  
left join maximo.LOCATIONS L_PG on PM.PRED = L_PG.LOCATION  
left join maximo.LOCATIONS L_MR on cs.PODRM=L_MR.LOCATION   
--left join maximo.WOSTATUS WS_con on WS_con.WONUM=PM.WONUM

where  ((WS.status ='COMP' and  WS.CHANGEDATE between  '2015-09-01' and '2015-11-01') or WS.status ='CONTR')
  
and pm.PMNUM is not null 
and pm.MONTHPLAN is not null
and L_MR.SHORTPATH like 'ПСПП/МУ/МГВП/%'  

) f

where  status!='COMP'

group by  WONUM,col1,col2,col3 ,col4,PMDUEDATE) ff
group by  col1,col2,col3 ,col4



Всем спасибо!
...
Рейтинг: 0 / 0
20.11.2015, 15:07
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Почему добавление еще одного условия в запрос увеличивает время исполнения в сотни раз
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]