Резко встала задача потюнинговать пару-тройку запросов. И тут обнаружился пробел Может кто-то проявит альтруизм и пояснит популярно на пальцах методику улучшения запроса путем анализа плана?
Вот дрозофила:
И, собственно говоря, три варианта запроса:
Планы - в attach'e. Вот исходя из каких критериев следует выбирать налилучший план запроса? Если посмотреть FINAL PLAN , то у 1-го и 2-го 1:1. А у 3-го - лучше
N total cost1 3552 3553 165.7
Но если посмотреть ниже, то
N lio pio cpu1 3 3 202 3 3 203 6 6 37
и т.д. Вот на что в первую очередь нужно смотреть при попытке анализа этих простыней?
Далее: если запрос на несколько порядков позаковырестей (как на рисунке ) - там видно, что некоторые ветки, по идее, могут выполняться параллельно. Где это можно посмотреть? Вот такое обнаружил (по рисунку)

( sort ( group_hashing ( nl_join ( nested ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( nl_join ( i_scan PK_INSURANCE_AGENTS ( table ( IA INSURANCE_AGENTS ) ) ) ( i_scan PK_CONTRACT_PAY ( table ( CP CONTRACT_PAY ) ) ) ) ( i_scan OBJECT_I_C_CONTRACT_ID ( table ( OIC OBJECT_INSURANCE_CONTRACT ) ) ) ) ( i_scan PK_INSURANCE_PRODUCT ( table ( IP INSURANCE_PRODUCT ) ) ) ) ( i_scan PK_INSURANCE_PRODUCT_PARAM ( table ( IPP INSURANCE_PRODUCT_PARAM ) ) ) ) ( i_scan PK_CONTRACT ( table ( C CONTRACT ) ) ) ) ( i_scan CONTRACT_ADD_INFO_CONTRACT_ID ( table ( CAI CONTRACT_ADD_INFO ) ) ) ) ( nl_join ( i_scan PK_CLIENTS ( table ( C CLIENTS ) ( in ( view vC2 ) ) ) ) ( i_scan PK_CLIENT_PARAM ( table ( CP CLIENT_PARAM ) ( in ( view vC2 ) ) ) ) ) ) ( i_scan uk_CONTRACT_PAY_PAY_BANK ( table ( CPPB CONTRACT_PAY_PAY_BANK ) ) ) ) ( i_scan CONTRACT_AGENTS_CONTRACT_ID ( table ( CA CONTRACT_AGENTS ) ) ) ) ( i_scan PK_CLIENTS ( table ( C CLIENTS ) ( in ( view vC1 ) ) ) ) ) ( i_scan PK_CONTRACT_PARAM ( table CONTRACT_PARAM ( in ( view CT1 ) ( view vCAI ) ) ) ) ) ( i_scan INSURANCE_AGENTS_PARAM_MI ( table ( IAP INSURANCE_AGENTS_PARAM ) ) ) ) ( i_scan PK_CONTRACT_PARAM ( table CONTRACT_PARAM ( in ( view CT2 ) ( view vCAI ) ) ) ) ) ( subq ( scalar_agg ( nl_join ( nl_join ( nl_join ( i_scan ACTIVITY_R_R_IN_PAYMENT_ID ( table ( ARR ACTIVITY_REPORT_RELATIONS ) ) ) ( i_scan PK_ACTIVITY_REPORTS ( table ( AR ACTIVITY_REPORTS ) ) ) ) ( i_scan PK_CONTRACT_PAY ( table ( CP_IN CONTRACT_PAY ) ) ) ) ( i_scan PK_CONTRACT_PAY ( table ( CP_OUT CONTRACT_PAY ) ) ) ) ) ) ) ( i_scan PK_CLIENT_PARAM ( table ( CP CLIENT_PARAM ) ( in ( view vC1 ) ) ) ) ) ) ) ( prop ( table ( IA INSURANCE_AGENTS ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CP CONTRACT_PAY ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( OIC OBJECT_INSURANCE_CONTRACT ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( IP INSURANCE_PRODUCT ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( IPP INSURANCE_PRODUCT_PARAM ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( C CONTRACT ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CAI CONTRACT_ADD_INFO ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( C CLIENTS ) ( in ( view vC2 ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CP CLIENT_PARAM ) ( in ( view vC2 ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CPPB CONTRACT_PAY_PAY_BANK ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CA CONTRACT_AGENTS ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( C CLIENTS ) ( in ( view vC1 ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table CONTRACT_PARAM ( in ( view CT1 ) ( view vCAI ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( IAP INSURANCE_AGENTS_PARAM ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table CONTRACT_PARAM ( in ( view CT2 ) ( view vCAI ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( ARR ACTIVITY_REPORT_RELATIONS ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( AR ACTIVITY_REPORTS ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CP_IN CONTRACT_PAY ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CP_OUT CONTRACT_PAY ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( CP CLIENT_PARAM ) ( in ( view vC1 ) ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) )

Здесь? Как? Сидеть считать скобочки? (это я, конечно, утрирую). В опчем: помогите кто чем может - не дайте помереть безграмотным
_________________
"Helo, word!" - 17 errors 56 warnings

Ggg_old
Определиться, какой у вас сервер ASA/ASE/IQ

I'm so sorry
select @@version
Adaptive Server Enterprise/15.0.2/EBF 14332/P/NT (IX86)/Windows 2000/ase1502/2486/32-bit/OPT/Thu May 24 04:10:36 2007

Ggg_old
Начните с графического плана и клацайте мышкой по квадратикам

Ну... Думаю по рисунку Вы догадались, что я так и делаю. Только вот засада: я такое могу проделать тока на своем локальном серваке 15-ке. А на боевом 12-ке вся эта кольоровость - недоступна. По сему и приходица рыться в тексте.
Ggg_old
Т.е. он вполне читабелен. У вас какой-то нечитабельный текст.

"...маємо те, що маємо...": маленькая простыня результат потуг set showplan on , большая dbcc traceon(3604, /*302,*/ 310) (302, как видите - за'rem'ил.) С 302 вообще как в том анеке: "...такие зверюги - им вообще автоматы не дают..."
Ggg_old
что-бы выполнении запроса использовались правильные индексы

Вот как раз на это смотрю и подгоняю в первую очередь. Но, согласно малюнку, все - зеленое (index scan)
Ggg_old
смотреть на то, как в плане оптимизатор оценил селективнойсть используемых параметров

ткните носом в простыню, pls...
Ggg_old
Критерием оптимальности обычно считается время выполнения запроса.

В принципе - да. Но ЭстЪ ньюансы: нагрузка на сервак, блокировки...
Ggg_old
старался минимизировать параметры логического чтения и записи как общий критерий сложности запроса вообще

Внимание - вопрос: посредством чего? Если, 4 example, страниц много данные выборки по ним разбросаны и происходит интенсивное вытеснение из кеша? Только индекс? Или есть ышо какие-то механизмы. Вот это хотелось бы чтобы озвучили. 4 example, я делаю пару-тройку join'ов и вижу, что если с'join'ить так, то, по идее, д.б. лучче. Вот как мне сказать "...ты туда не ходи, ты сюда ходи..."? хинты?
Ggg_old
рано или поздно прийдется пройти и через эти тонкости

Ну вот воно - вже... Просто все буквари/мануалы по этой теме носят описательный характер. Я, конечно, понимаю, что все зависит от конкретно взятых данных и запросов. Но все же можно же привести какую-нить дрозофилу и на пальцах показать: смотрим на это и это, а уж потом на это и то. Ведь оптимизация многокритериальная. Т.е. одно у одного м.б. лучше, а у другого - другое. И что тогда предпочесть?
_________________
"Helo, word!" - 17 errors 56 warnings
Posted via ActualForum NNTP Server 1.4

MasterZiv
Ваша задача - заставить оптимизатор выбрать хороший план, а не понять, почему он его не выбирает.

Гм... IMHO, во-первых: для того, чтобы бороться с врагом, нужно его изучить. Во-вторых: для того, чтобы заставить оптимизатор выбрать хороший план, нужно же как-то выбрать этот самый хороший. Вот в дрозофиле: 1-й запрос - отпадает, понятное дело. А какой лучше/хуже: 2-й или 3-й? Исходя из каких критериев это определить?
MasterZiv
должны уже сами знать, как должен выполняться ваш запрос

Да вот как-то теория с практикой не сростается... Вот, 4 example:
Table T1 - 5 записей
Table T2 - 5000 записей
Table T3 - 50000 записей
и
Пример гипотетический, но приблизительно такая ситуация в реальной жизни имела место. По идее, оптимально, в начале с\'join\'ить T1 и T2, а уж потом к полученному результату при\'join\'ивать T3. На деле же получается в начале join T2 и T3, а потом уже при\'join\'ивается T1.
Или, вот другой случай. Тогда как узнать как должен выполняться запрос?
MasterZiv
Потому что плохо написанный запрос никогда не будет работать быстро.

Это понятно? Но как определить, что он плохо написан? По in (select )? Это хорошо, если это ЭстЪ? А если - нЭт.
MasterZiv
(продолжение следует)

Это - радует. Только, вот, все равно хочется немного от теории перейти к практике.
Ggg_old
Старайтесь избегать вложенных запросов типа Id not in (select Id from T2) и not exists (select Id from T2 where Id=T1.Id)

Да, вот, как раз попалось на глаза . И решил на этих кошках потренироваться... BTW, прогнал их же в IBExpert\'е (там тоже неплохо организован анализ планов) - дык там шо not exists, шо left join - 1:1-му
_________________
"Helo, word!" - 17 errors 56 warnings
Posted via ActualForum NNTP Server 1.4

Ex_Soft
Или, вот другой случай

Распишу, так сказать, на пальцах ( T1 && T2 ):
T1
IdValue1\'1_T1\'2\'2_T1\'3\'3_T1\'4\'4_T1\'5\'5_T1\'
T2
IdValue1\'1_T2\'3\'3_T2\'5\'5_T2\'
T4
GroupIdIdVal11\'string value #1_1\'12\'string value #1_2\'13\'string value #1_3\'21\'1\'22\'3\'23\'5\'31\'string value #3_1\'32\'string value #3_2\'33\'string value #3_3\'
Что там получилось: если в начале сделать join T1 с T4, то тогда в T4 остаются только записи из GroupId=2 и cast при join\'е с T2 происходит без проблем. А оптимизатор решил в начале с\'join\'ить T4 с T2. Отсюда и

Syntax error during explicit conversion of VARCHAR value \'string value #1_1\' to a INT field.

Вот что ему нуна было сказать, чтобы он в начале join\'ил T1 с T4?
_________________
"Helo, word!" - 17 errors 56 warnings

MasterZiv
надо уметь работать ЗА оптимизатор

Как было показано выше, вроде бы вполне логичные "...мои мысли - мои скакуны..." не всегда совпадают с мнением оптимизатора. Вот тут и встает вопрос: почему? кто из нас прав?
MasterZiv
о планах РАЗНЫХ запросов рассуждать бессмысленно

Давайте определимся с терминологией: что в Вашем понимании разные запросы? Которые синтаксически выглядят по разному? Для меня, если запросы, на одном и том же множестве исходных данных возвращают одинаковый результат - одинаковы и сопоставимы. В конце концов: оптимизация - процесс итерационный. Тогда, получается, результаты каждой итерации не имеет смысла сравнивать. А как же тогда быть? Вот на пальцах: у меня не слабый запрос с кучей join'ов, агрегированием и условий. И одно из условий NOT IN. Я заменил его на NOT EXIST (LEFT JOIN). Это уже разные запросы? Другой пример: пара-тройка join'ов используется многократно и в нескольких местах - оформил как view и, соответственно, заменил в запросе. Это тоже уже будут разные запросы?
Получается оптимизация тогда тока и заключается в том, чтобы индекса только прикручивать, оставляя при этом зам запрос неизменным? Т.е. если я добился, грубо говоря, везде index scan и запрос, все равно вводит сервак в down, то списываем его как на неоптимизируемый и умываем руки?
_________________
"Helo, word!" - 17 errors 56 warnings
Posted via ActualForum NNTP Server 1.4

BTW, вот ( вот ), что надыбал... ( отсюда )
/me думает: чем дальше в лес, тем толще партизаны...
_________________
"Helo, word!" - 17 errors 56 warnings
Posted via ActualForum NNTP Server 1.4

По мотивам получил

( nl_join ( nl_join ( i_scan pkT4 ( table ( T4 T4 ) ) ) ( i_scan pkT1 ( table ( T1 T1 ) ) ) ) ( i_scan pkT2 ( table ( T2 T2 ) ) ) ) ( prop ( table ( T4 T4 ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( T1 T1 ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) ) ( prop ( table ( T2 T2 ) ) ( parallel 1 ) ( prefetch 2 ) ( lru ) )

"посчитал скобочки"
теперь, вроде, видно, что с начала, если имеет место FIFO в описании, идет join T1 и T4, а потом к результату T2. А вот это

parallel 1

везде, что они выполняются в одной параллели? Т.е. последовательно? Т.е. если сдесь тока parallel 1 , то он весь выполняется последовательно, хотя, вроде, по его раскидистому дереву, некоторые ветки могли свободненько выполниться паралельно?
_________________
"Helo, word!" - 17 errors 56 warnings
Posted via ActualForum NNTP Server 1.4