|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Добрый день Как понять, что именно зависает в запросе? Вот сейчас у меня он в зависшем состоянии, что посмотреть? dm_os_waiting_tasks ничего не показывает по этой сессии. Запрос несложный, и данных немного. Зависание воспроизводится на разных серверах, но нерегулярно. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 08:26 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Результат WhoIsActive после часа выполнения ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 08:26 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Ну, #tt20 WITH (TABLOCK) еще можно как-то понять... ну типа, минимальное логгирование включится. Но нахера? На времянках NOLOCK? #tt7 T2 WITH (NOLOCK) Вот вам сервер и мстит. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 08:50 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Типичное поведение, когда в запросе есть NL, где на внутреннем входе таблица с большим числом строк, а на внешнем с маленьким, согласно оценке. В реальности же на внешнем входе тоже много строк. У вас два таких NL. Сколько реально строк в #tt2, #tt7 и #tt19? ЗЫ: Для временных таблиц TABLOCK и NOLOCK смысла не имеют. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 09:02 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
invm, размеры таблиц: #tt2 2 #tt7 159 #tt19 855 000 это запросы от 1с, подобные хинты нигде проблем не вызывают ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 09:48 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
invm на внешнем с маленьким, согласно оценке. В реальности же на внешнем входе тоже много строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 10:07 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
invm Типичное поведение, когда в запросе есть NL, где на внутреннем входе таблица с большим числом строк, а на внешнем с маленьким, согласно оценке. В реальности же на внешнем входе тоже много строк. Я подозреваю что проблема решается просто, перегруппировкой запроса или типа того. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 10:29 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0 invm Типичное поведение, когда в запросе есть NL, где на внутреннем входе таблица с большим числом строк, а на внешнем с маленьким, согласно оценке. В реальности же на внешнем входе тоже много строк. Я подозреваю что проблема решается просто, перегруппировкой запроса или типа того. У Вас жизнь портят вот эти два момента: Код: sql 1. 2. 3.
по план у они дают сканирование достаточно больших таблиц #t17 => 612855 #t16 => 675339 на внешнем входе nested loop думайте как решать сами, или переписывать запрос или индексировать поле _Q_001_F_001RRef ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 10:50 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0 Можете объяснить механику процесса? Например, если взять второй NL из вашего плана, - там по оценке на внешнем входе одна строка. Соответственно, сканирование таблицы из 600000+ строк на внутреннем входе должено бы выполниться только один раз. Теперь представьте что произойдет, если при выполнении запроса на внешнем входе будет 1000 строк, а не 1. ЗЫ: В пользу версии с NL говорит количество чтений в результате WhoIsActive. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 10:51 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
соглашусь, что действительно дело может быть в nested loops, т.к. когда запрос выполняется без зависаний, то в плане запроса нет nested loops, а только hash match, при аналогичных размерах таблиц ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 11:04 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
смущает только, что запрос зависает намертво выполняется больше суток и конца и края не видно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 11:15 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0 смущает только, что запрос зависает намертво выполняется больше суток и конца и края не видно он не зависает, он дофигища вычитывает строк по многу-многу раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 11:35 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
felix_ff, да, я это образно про зависание. В WhoIsActive видно, что логические чтения растут. Похоже что действительно неоптимальный план случается, т.к. по моим ручным расчетам получается что перед двумя тяжелыми нестедлупсами будут сотни тысяч строк, а в оценочном плане одна строка почему то. Если сейчас выполняю этот же запрос на этих же данных то план строится другой, который выполняется мнгновенно. В общем, т.к. план нестабильный то надо запрос упрощать. Я так понял. Быстрый план: (имена таблиц другие) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 12:13 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0, Попробуйте добавить к запросу option(recompile) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 12:37 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
invm vi0, Попробуйте добавить к запросу option(recompile) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 12:51 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Все таки интересно, почему строится насколько неоптимальный план? Допустимо ли такое для новых временных таблиц? Хотя я допускаю, конечно, что таблицы были уже, но пустые и переиспользовались, и план соответственно тоже был в кэше. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 15:13 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0 invm vi0, Попробуйте добавить к запросу option(recompile) возможности добавить индекс на временную таблицу у Вас тоже нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 15:29 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
felix_ff возможности добавить индекс на временную таблицу у Вас тоже нет? есть, но вопрос ведь в том что план сильно некорректный и воспроизводится это нерегулярно согласитесь? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 15:42 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0 felix_ff возможности добавить индекс на временную таблицу у Вас тоже нет? есть, но вопрос ведь в том что план сильно некорректный и воспроизводится это нерегулярно согласитесь? вы несколько лукавите в плане предоставления данных: у вас на скрине план запроса с hash-match join-ми используется как начальный вход таблица #tt3 которой нет в изначальном запросе топика. Выбор между операторами соединения NL/HM/MJ зависит от достаточно многих факторов. могу предположить что в какие то моменты у вас достаточно сильно меняется оценка кардинальности предикатов. обычно с оценкой кардинальности темповых таблиц у сиквела все нормально. поскольку оптимизатор выбирает план запроса по cost-based модели у вас в каких то некоторых случаях план запроса с NL дешевле чем Hash. вы можете поэкспериментировать сами на данных когда план запроса с NL и когда с HS в ssms просто на копии этих данных смоделируйте копию плана с помощью жекстого хинтования INNER HASH|LOOP JOIN и смотрите общую оценку планов в попугаях. (понятно что вам нужно будет также все настройки сессии привести в соответствие с теми что используются при подключение из 1c) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 16:04 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
felix_ff вы несколько лукавите в плане предоставления данных: у вас на скрине план запроса с hash-match join-ми используется как начальный вход таблица #tt3 которой нет в изначальном запросе топика. я написал что "(имена таблиц другие)" - при выполнении запроса платформа 1с динамически назначает имена временных таблиц я также написал что на тех же данных на той же базе у меня получился другой план база моя тестовая. не менялась в течение дня ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 16:16 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
вообще 1с не всегда пересоздает новые временные таблицы, иногда может использовать прежние в течение сеанса, если их структура такая же вот здесь у меня подозрение - что использовался план запроса из кэша для другого наполнения этих таблиц ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 16:19 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
felix_ff Выбор между операторами соединения NL/HM/MJ зависит от достаточно многих факторов. могу предположить что в какие то моменты у вас достаточно сильно меняется оценка кардинальности предикатов. обычно с оценкой кардинальности темповых таблиц у сиквела все нормально. поскольку оптимизатор выбирает план запроса по cost-based модели у вас в каких то некоторых случаях план запроса с NL дешевле чем Hash. вы можете поэкспериментировать сами на данных когда план запроса с NL и когда с HS в ssms просто на копии этих данных смоделируйте копию плана с помощью жекстого хинтования INNER HASH|LOOP JOIN и смотрите общую оценку планов в попугаях. (понятно что вам нужно будет также все настройки сессии привести в соответствие с теми что используются при подключение из 1c) Попробую может эксперименты с хинтами, но чисто для расширения картины ситуации, может быть увижу что то. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 16:31 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
vi0, в каком смысле - некорректный? Любой план, который приводит к нужному результату - корректен. Оценка статистики подчиняется определённым законам. Скорее всего, вы создаете временную таблицу и добавляете в нее большой объём данных. Попробуйте потом создать статистики для этой таблицы с учетом столбцов запроса и проверьте план. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2020, 17:28 |
|
Как понять что зависает в запросе?
|
|||
---|---|---|---|
#18+
Владислав Колосов, План некорректный т.к. нужного результата нет, если выражаться вашими словами. В теории он должен давать результат. а по факту выливается в переборы которые занимают неопределенное количество времени - небольшой запрос выполнялся больше суток и его приходится прерывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2020, 04:27 |
|
|
start [/forum/topic.php?fid=46&msg=39973187&tid=1685868]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
125ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 265ms |
total: | 490ms |
0 / 0 |