|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Коллеги, приветствую! Помогите не сойти с ума -) Выполняю запрос, в плане вижу, что чтение идет сначала из таблицы AccumRgT106, потом из AccumRg102. Читаю план как обычно, справа на лево, сверху вниз. Но блокировки по какой-то причине накладываются сначала на таблицу AccumRg102, и только потом на AccumRgT106. Проверял с помощью расширенных событий, скрины трассировки и сам план запроса прикладываю. Почему так происходит? Что я делаю не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 00:09 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович, у вас оператор соединения merge join, для него потоки входа что правый что левый запускаются почти одновременно. (это типо неблокирующий оператор) поэтому тут нет ничего удивительного что может блокировка сначало наложиться на ресурсы правого входа оператора соединения. add:точнее не совсем так как я написал, точка входа для первого сканирования выбирается исходя из кол-ва строк (вроде) для оператора при merge join (но это не точно :) ) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 02:49 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
felix_ff, И даже то что у него MAXDOP=1, это не влияет? Просто уточняющий вопрос, я не очень хорошо в этом понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 03:16 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Marat2020, не должно, я понимаю если бы оператор был бы HJ или NL там первым обрабатывается левый вход. конкретного описания технологии реалализации в sql server оператора к сожалению нет. можно только догадываться с какого входа начинается сканирование. те материалы которые встречались лично мне описывали начало обхода левого входа, но судя по приложенным ТС данным и общей концепции работы самого оператора предполагаю что сканирование может начинаться и с правого входа. другое дело что в плане присутствует блокирующий оператор сортировки для правого входа, и получается что обработка правого входа получается несколько "оперативней" чем начало сканирования для левого входа. этот факт выглядит весьма занятным ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 03:43 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
felix_ff, Спасибо за пояснение! Но я не понимаю, почему наличие сортировки на правом входе, делает этот вход более "оперативным"? Разве за счет сортировки он не должен наоборот немного отставать от левого входа? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 09:10 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Marat2020, Стоимость плана слишком мала что бы включилось распараллеливание. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 09:19 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович, У вас 2019 RTM. После обновления до последнего CU чудеса могут исчезнуть. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 10:36 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Какая разница - в каком порядке подаются строки? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 10:58 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
invm, Обновил, чудеса продолжаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:05 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Владислав Колосов, 1. Вся каша заварилась из-за того, что появился дедлок. Причину дедлока я понимаю и знаю как устранить, но в процессе расследования выяснился такой нюанс, что таблицы могут блокироваться не в том порядке как это указано в плане. 2. Как минимум то что план не соответствует фактическому выполнению кажется мне весьма странным, и очень похоже на ошибку. В следствии этого расследование проблем с дедлоками может занять больше времени чем следовало бы. А так то разницы никакой ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:09 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович, В "нижней" ветки у вас sort. Это блокирующий оператор, и до его окончания нет смысле получать "верхний" поток. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:12 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
msLex, Ок, допустим, но почему тогда не сделать это ветку левой, что план можно было читать как обычно? Разрабы не досмотрели? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:16 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович msLex, Ок, допустим, но почему тогда не сделать это ветку левой, что план можно было читать как обычно? Разрабы не досмотрели? Зачем? В плане все верно. В мерж потоки поступают именно в том порядке, который указан в плане. Просто для получения одного из потоков требуется дополнительные действия. Сортировка. До ее окончания, потоки для мерж вообще не читаются. Т.к. в этом просто нет смысла. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:24 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
msLex, Если читать план справа на лево, сверху вниз, то первым в плане выполняется чтение AccumRgT106, но блокируется сначала AccumRg102. Что же тут верного? Или вы предлагаете читать план другим способом? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:27 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
msLex, > Просто для получения одного из потоков требуется дополнительные действия. Сортировка. До ее окончания, потоки для мерж вообще не читаются. Т.к. в этом просто нет смысла. Это я понимаю, я не понимаю почему вход с сортировкой отображается на правом входе, а не на левом. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:30 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович msLex, Если читать план справа на лево, сверху вниз, то первым в плане выполняется чтение AccumRgT106, но блокируется сначала AccumRg102. Что же тут верного? Или вы предлагаете читать план другим способом? Я предлагаю читать план именно так, как он работает. Причину, по которой именно так поступает SQL Server вам уже объяснили. Дальнейшие "пререкания" на эту тему, не более чем демагогия, только от которой = 0 Просто чтобы вы понимали. В merge join порядок входящих потоков влияет не только на то из какой из них первой будет вычитана 1-я запись, но и направление "локальных cross join nested loop-ов" в случае одинаковых неуникальных значений в обоих потоках данных, а может еще куча других скрытых от нас действий. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:39 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович Это я понимаю, я не понимаю почему вход с сортировкой отображается на правом входе, а не на левом. Потому что в рамках merge join, поток данных после сортировки действительно "правый". И когда данные отсортированы, сначала будет прочитана 1-я запись из левого потока, а только потом 1-я запись из правого потока. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 11:41 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
msLex, Правильно ли я понимаю, что оптимизатор по какой-то (неведомой нам причине) решил на левый вход для MJ подать результат чтения первой таблицы, а на правый, результат чтения второй таблицы. Хотя там идет операция Concatenation и по идее порядок вообще не важен. При выполнении, СУБД увидела что в правом входе есть Sort, и выполнять чтение в левом бессмысленно, пока не выполнен Sort. Идет чтение второй таблицы, потом идет Sort и данные подаются в MJ. Потом идет чтение первой таблицы из левого входа и только после этого идет объединение. Все верно? Просто действительно хочу разобраться в нюансах на будущее, что бы правильно читать планы. Вчера убил весь день, что бы понять почему происходит дедлок пока не возник этот когнитивный диссонанс. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 12:45 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович msLex, Правильно ли я понимаю, что оптимизатор по какой-то (неведомой нам причине) решил на левый вход для MJ подать результат чтения первой таблицы, а на правый, результат чтения второй таблицы. Хотя там идет операция Concatenation и по идее порядок вообще не важен. При выполнении, СУБД увидела что в правом входе есть Sort, и выполнять чтение в левом бессмысленно, пока не выполнен Sort. Идет чтение второй таблицы, потом идет Sort и данные подаются в MJ. Потом идет чтение первой таблицы из левого входа и только после этого идет объединение. Все верно? Просто действительно хочу разобраться в нюансах на будущее, что бы правильно читать планы. Вчера убил весь день, что бы понять почему происходит дедлок пока не возник этот когнитивный диссонанс. Судя по плану, порядку наложения блокировок и логике почти так. После окончания sort начинаю читаться данные из "левой" таблицы и следом данные из "правого" потока, которые уже собраны в операторе sort. Не думаю, что стоит заморачиваться с запоминанием, как это работает прямо сейчас, т.к. это ни где официально не задокументировано, а значит может измениться в любой момент. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 12:53 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
msLex, Теперь понял, спасибо! Очень конечно меня удивляет этот факт, всегда думал что порядок отображения в плане, совпадает с порядком выполнения операторов. Ушел думать о несовершенстве бытия. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 13:00 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович, Алгоритм merge join - https://sqlserverfast.com/epr/merge-join/ Там же, в разделе "Concatenation", описан ваш случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 13:11 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
invm, Прочитал, но свой случай, к сожалению, там не увидел. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 13:37 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
Андрей_Батькович Коллеги, приветствую! Помогите не сойти с ума -) Выполняю запрос, в плане вижу, что чтение идет сначала из таблицы AccumRgT106, потом из AccumRg102. Читаю план как обычно, справа на лево, сверху вниз. Но блокировки по какой-то причине накладываются сначала на таблицу AccumRg102, и только потом на AccumRgT106. Проверял с помощью расширенных событий, скрины трассировки и сам план запроса прикладываю. Почему так происходит? Что я делаю не так? А кто тебе вообще сказал, что порядок блокировки таблиц как-то вообще определён, на ещё и определяется планом? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 15:36 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
MasterZiv, Давайте все таки на Вы. А чем же он по вашему определяется? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 15:43 |
|
Порядок блокировки таблиц не соответствует плану запроса
|
|||
---|---|---|---|
#18+
MasterZiv, разумеется планом, чем же еще? Существует поставщик строк, который не отображается на плане. Этот поставщик действует согласно плана, до прохождения блокирующего оператора он может не накладывать блокировки для чтения данных таблиц, которые используются позже, согласно плана запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.02.2021, 16:10 |
|
|
start [/forum/topic.php?fid=46&msg=40046105&tid=1685068]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
130ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 237ms |
0 / 0 |