| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Oracle |
  |
||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 4 [5] все |
 Re: Проседание времени выполнения запроса
|
|||||||
|
Dimitry Sibiryakov Member Откуда: Сообщений: 47373 |
Насколько неполноценен твой доступ? Ты не в состоянии послать запрос к системным вьюхам чтобы проверить наличие и статус нужных твоему запросу индексов?
Так почему написал запрос, который совершенно не использует индексы? Вредитель? Мазохист?..
То есть для тебя знать задуманный собой способ выполнения запроса и найти отличие от реального - сложно? В детском саду есть такое упражнение для развития мозга: "найди 10 отличий между картинками". Стоило больше тренироваться, наверное. Posted via ActualForum NNTP Server 1.5 |
||||||
| 6 дек 18, 13:38 [21755751] Ответить | Цитировать Сообщить модератору | |||||||
| Re: Проседание времени выполнения запроса
|
||||
|
xtender Member Откуда: Мск Сообщений: 5076 |
 1. я оооочень сомневаюсь, что повлияло изменение кардинальности подзапроса с деревяшкой(MY_PC), если это эксплейн с продуктивной базы, то врядли изменение до 3364 могло оказать такое воздействие. Гораздо более вероятно, что повлияло изменение статистик по TP_ZAG/TP_ZAG_XXX, в больше степени влияющих на получение запредельных E-ROWS=205G 2. да, конечно, можно обойтись одним хинтом cardinality, но воткнуть таких хинтов придется много и текущей информации слишком мало, чтобы выставить правильные/подходящие значения везде 3. с точки зрения упрощения задачи, даже при отсутствии плана в AWR или отсутствии пака(судя по тому, что они используют partitioning views, врядли у них приобретены diagnostics+tuning), можно просто вернуть/посмотреть старую статистику и получить старый план 4. если уж не менять запрос, то я бы предпочел полноценно хинтовать(или закреплять профилем), то есть полным и однозначным набором хинтов: leading+use_xxx+index/full и тд 5. тексты вьюх, предикаты, алиасы и проекции не приведены, и без этой информации нормально проанализировать не получится, например 5.1 в части
FROM
(
SELECT
part_aid,
proj_aid,
count_pc,
vargrp,
varnum
FROM
sysdba.pc pc,
zebra.zebra_all_sect zas,
sysdba.articles art
WHERE
pc.part_aid = zas.art_id
AND zas.otr_konstr IS NOT NULL
AND SN NOT IN (1, 148)
AND pc.proj_aid =art.art_id
AND pc.proj_ver_id = art.art_ver_id
)
START WITH part_aid IS NOT NULL
AND vargrp = 0
AND varnum = 0
CONNECT BY PRIOR proj_aid = part_aid
)
непонятно из какой таблицы берутся vargrp, varnum, SN 5.2 каковы предикаты внутри ZEBRA_ALL_SECT 5.3 откуда там outer джойны, группировки, сортировки - в предоставленном запросе их нет. Это особенно хорошо видно, если схлопнуть MY_PC и ZEBRA_ALL_SECT в плане
5.4 без статистик и предикатов непонятны кардинальности и имеет ли смысл по многу раз начитывать одни и теже таблицы 5.5 без ddl таблиц с констрейнтами трудно понять, чего вообще автор хочет, например, если part_aid уникален, то "sysdba.articles art" джойнится зря(а если не уникален, то джойн бестолково размножает строки), т.к. исходя из текста запроса, это условие по нему можно было сразу указать в start with:
(
SELECT
lvl,
ISLEAF,
root_part_aid,
root_proj_aid,
part_aid,
proj_aid,
count_pc ,
... AS paths
FROM
(
SELECT
level AS lvl,
CONNECT_BY_ISLEAF AS ISLEAF,
CONNECT_BY_ROOT part_aid AS root_part_aid,
CONNECT_BY_ROOT proj_aid AS root_proj_aid,
part_aid,
proj_aid,
count_pc ,
ltrim(SYS_CONNECT_BY_PATH(count_pc, '*'),'*') AS paths
FROM
(
SELECT
part_aid,
...
FROM
sysdba.pc pc,
zebra.zebra_all_sect zas,
sysdba.articles art
WHERE
pc.part_aid = zas.art_id
AND ...
AND pc.proj_aid = art.art_id
AND ...
)
START WITH part_aid IS NOT NULL
...
CONNECT BY PRIOR proj_aid = part_aid
)
)
WHERE
ISLEAF = 1
)
my_pc
...
WHERE
...
AND art.art_id = tobj.f_art_id
AND art.purchased IS NULL
...
AND zas.art_id = tobj.f_art_id
AND zas.kod_odi IS NOT NULL
AND my_pc.root_part_aid = tobj.f_art_id
то есть транзитивно my_pc.root_part_aid = art.art_id, а root_ - это корни дерева, и кроме предиката "art.purchased IS NULL" больше причин джойнить art нет. А так как деревяшка идет по инлайн вью, которая тоже тупо джойн(причем мы еще не знаем деталей остальных предикатов в ней), то можно просто внутрь просунуть предикат "pc.purchased IS NULL"5.6 такая же хрень и с AND zas.art_id = tobj.f_art_id AND zas.kod_odi IS NOT NULL ... AND my_pc.root_part_aid = tobj.f_art_id т.к. tobj.f_art_id - это тоже равно my_pc.root_part_aid ----- устал пока писать, потом продолжу... |
|||
| 6 дек 18, 13:43 [21755760] Ответить | Цитировать Сообщить модератору | ||||
| Re: Проседание времени выполнения запроса
|
|
|
Ryuu Member Откуда: Сообщений: 545 |
xtender, я вам благодарен, что вы пытаетесь разобраться. Правда. Но есть один нюанс, который я не сказал, вернее, который упоминался, но он не очевиден. План запроса... от другого запроса, более тяжелого. Выложил лишь "ядро", причем несколько видоизмененное (не все поля вытащил, там где стоит tobj.*, некоторые данные есть только в тех "бессмысленных", на первый взгляд, таблицах). Для теста он более чем подходил, так как уже там сыпался. А план... как я уже упоминал, я не планировал разбираться в запросе или ещё в чем. Выложил тот, что был, и смотрел я по таймингам. Там, к слову, всё связано по индексам и нужно. Лишнего нет. Думал, мне укажут на настройку или параметр базы. На худой конец, скажут, что дерьмо случается и нужно переписать запрос, баг. Сейчас я этим вопрос не занимаюсь от слова совсем, и не планирую. Просто поглядываю тему, отчего и неудобно немного. И да, поля из таблицы pc. ZAS - это вьюшка, через union all объединяет разные таблицы, решение такое себе, но интермех альтернативу не предоставляет. И да, part_aid уникальны. В общем, если вы решили "оценить" сам запрос, занятие весьма спорное. Впрочем, я вас не от чего не отговариваю. -2- , я со второй страницы говорю, что тема уже неактуально и я в ней более не разбираюсь, лишь отвечаю на провокации. Ума, видимо, проигнорировать всё же не хватает. env, как вы с Dimitry Sibiryakov общаетесь в своей высокомерной манере, так вам и отвечаю. Поверьте, если бы мне в реале открыто хамили, то я точно так же бы в реале послал наглеца погулять. На этом наше "общение" с вами закончено. |
| 6 дек 18, 16:29 [21756069] Ответить | Цитировать Сообщить модератору | |
| Re: Проседание времени выполнения запроса
|
|
|
Ryuu23 Member Откуда: Сообщений: 1 |
Ох, пришлось зарегестрироваться, чтобы внести небольшую правку. Всё моя невнимательность.Немного соврал. Part_aid был уникален до того момента, как в интермехе появились версии в этой таблице, связка с articles нужна, чтобы подтянуть актуальную версию.И да, раз уж меня забанили... хм. Ну и ладно. Пока. :) |
| 6 дек 18, 16:43 [21756090] Ответить | Цитировать Сообщить модератору | |
| Re: Проседание времени выполнения запроса
|
|||||||||
|
env Member Откуда: Россия, Москва Сообщений: 5929 |
Тебе это говорят чуть ли не с первой страницы. Но ты упорно игнорировал это и
Как настройка или параметр повлияет на другие твои запросы, думать за тебя, видимо, тоже должны другие.
Вот уж точно, "у меня в подвале странный стук".
Т.е. в реале тоже на "высокомерие" отвечаешь хамством и матом? Ну хоть сам признал. Ещё есть шанс обрести воспитание и исправить речь. |
||||||||
| 6 дек 18, 17:31 [21756158] Ответить | Цитировать Сообщить модератору | |||||||||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 4 [5] все |
| Все форумы / Oracle | |
|
x