|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Добрый день всем. SQL 2012 Есть несложынй запрос Очень тормозящий при одном значении - вместо 10 сек работает > 5 мин и яего снимаю Код: 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. 28. 29. 30.
@id_param - я подставляю конкертные значения и запускаю в SSMS И вот с одинм значением виснет реально связано нав. с етм что при этом параметре общий резалтсет запроса пустой (подзапрос возвращате 16 000 записей ) (прричем резалтсет там не может быть больше 15 записей !! ) NOT IN - ясно не лучший выбор и LEFT JOIN решает проблему - все работает за 2 сек Estimated plan вытаскивается без проблем ( приатачил его ) а вот как вытащить Actual Execute plan при проблемном значении если запрос виснет в SSMS (и SentryOne Plan Explorer )? я понимаю что это parametr sniffing - и план сохраненный для одного значения ведь в другом случае подзапрос вовзваращет 32000 записей - работате чуть дольше т.е разница походу в том что с проблемным значением общий резалтсет пустой но хочется понять причину ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2020, 19:28 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Гулин Федор как вытащить Actual Execute plan при проблемном значении если запрос виснет в SSMS (и SentryOne Plan Explorer )? Гулин Федор Estimated plan вытаскивается без проблем ( приатачил его ) Давайте оценочный план с ffca.id_command = @id_param ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2020, 20:05 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2020, 20:32 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
invm, +1. сам недавно наткнулся на тяжелый запрос с not in(), который из-за nested loop отрабатывал очень долго, после переписывания в not exists() - практически мгновенно ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 02:35 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
invm Нет Nolock убрал - ничего не изменилось так я запускал запрос с конкетным значением = 40 он также тормозит поэтому и план от него. тормозит (точнее вешает )и при вызове из SP с параметром и с одним конкертным значением ps счас проверю 99% Not Exists тоже поможет ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 09:18 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
также тормозит (виснет) с одним значением - план похоже тот же Код: 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. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 09:32 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Гулин Федор, Сколько строк в F_Firm_CommandAgent для id_command = 40? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2020, 12:21 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Гулин Федор, авторИ вот с одинм значением виснет реально первое, что приходит в голову - ошибка в оценке кардинальности. В результате оптимизатор предполагает, что в наборе будет одна строка, а их намного больше. Кроме того, может не использоваться параллелизм из-за ошибочной оценки времени выполнения. Смотрите на план запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2020, 13:50 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
прогнал еще 1 раз с утра Код: sql 1. 2. 3. 4.
Если прописать @id_param = 40 то отрабатоло за 1.5 минуты (медленно - но все таки отработало ) а если захрадкодить ffca.id_command = 40 то > 5 мин и я снимаю Прилагаю actial plan ffca.id_command = @id_param -- 40 к-й отрабоал Estimated plan for ffca.id_command = 40 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 09:50 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
оказыается нельзя 2 атачмента к 1 сообщения прилагаю esitm_plan_for_40_HARDCODE.sqlplan ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 09:51 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Код: 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. 28. 29. 30. 31. 32. 33.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 10:38 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
Гулин Федор, Для начала обновите статистику для всех таблиц и индексов из запроса с FULL SCAN ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 10:46 |
|
NOT IN Actual Executed plan достать если запрос виснет
|
|||
---|---|---|---|
#18+
invm, ДА с этого наверно надо было и начинать - я обновил 2 таблицы в подзапросе а надо было ВСЕ подозреваю что дело было в CmClient2SalesChannel она красным подсвечитвается в SQL Sentry (RID Lookup ) Код: sql 1.
RID Lookup - это Full Scan ?? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2020, 11:51 |
|
|
start [/forum/topic.php?fid=46&msg=39918078&tid=1686600]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 144ms |
0 / 0 |