Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 План исполнения запроса.  [new]
VitLF
Member

Откуда:
Сообщений: 339
Объясните пожалуйста, из-за чего может меняться план исполнения запроса в MSSQL на один и тот-же запрос на том же сервере?
30 янв 12, 10:02    [11994237]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
VitLF
Объясните пожалуйста, из-за чего может меняться план исполнения запроса в MSSQL на один и тот-же запрос на том же сервере?
Из за изменения данных в таблицах, изменения доступной памяти, загруженности процессоров, изменения скорости работы дисков.
30 янв 12, 10:07    [11994288]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
VitLF
Member

Откуда:
Сообщений: 339
А от фрагментации индексов может меняться?
30 янв 12, 10:15    [11994338]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35376
Блог
изменения SET`ов подключения, рестарта сервера
30 янв 12, 10:16    [11994343]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
VitLF
А от фрагментации индексов может меняться?
Вроде нет, но ведь фрагментация не возникает без изменения данных, а при изменении данных может...
30 янв 12, 10:45    [11994538]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35376
Блог
alexeyvg,

а сжатие базы?
30 янв 12, 11:59    [11995151]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
alexeyvg
изменения доступной памяти, загруженности процессоров, изменения скорости работы дисков.

А когда SQL Server вдруг начал учитывать эти параметры?
30 янв 12, 12:29    [11995387]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Ray D
alexeyvg
изменения доступной памяти, загруженности процессоров, изменения скорости работы дисков.

А когда SQL Server вдруг начал учитывать эти параметры?

"изменения доступной памяти" - Это учитывает точно, Conor про это писал у себя в блоге. От количества доступной памяти зависит то насколько эффективно сервер может делать hash join и сортировку в памяти.
"загруженности процессоров" - Очень сомневаюсь. Если только все CPU не были загружены на 100% в момент построения запроса и связи с этим был выбран неоптимальный план по таймауту.
"изменения скорости работы дисков" - вот на это серверу однозначно фиолетово. Если заменить обычные диски на SSD оптимизатор даже не заметит. Я думаю это было сделано в практических целях. Оценка скорости дисков или фрагментации или еще чего подобного в момент построения плана уж очень ресурсоёмкая задача, которая при этом редко имеет практический смысл. У Конора опять же по этому поводу было написано.
30 янв 12, 21:22    [11999554]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Ray D
alexeyvg
изменения доступной памяти, загруженности процессоров, изменения скорости работы дисков.

А когда SQL Server вдруг начал учитывать эти параметры?
Насколько я помню, сиквел оценивает производительность дисковой системы и процессора в каких то своих "пунктах", и учитывает это при построении плана.

Вот про память, например, заметка ещё про 7.0: http://www.hardline.ru/2/13/499
Из неё: "Если build input ненамного превышает размер доступной памяти, SQL Server 7.0 использует hybrid hash join."
Mind
"изменения скорости работы дисков" - вот на это серверу однозначно фиолетово. Если заменить обычные диски на SSD оптимизатор даже не заметит.
Про процессор на 100% не уверен, но про диски помню...
30 янв 12, 21:41    [11999665]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
alexeyvg
Ray D
пропущено...

А когда SQL Server вдруг начал учитывать эти параметры?
Насколько я помню, сиквел оценивает производительность дисковой системы и процессора в каких то своих "пунктах", и учитывает это при построении плана.
Ага. Только они фиксированы и вшиты в оптимизатор.
30 янв 12, 21:43    [11999681]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Гавриленко Сергей Алексеевич
alexeyvg
пропущено...
Насколько я помню, сиквел оценивает производительность дисковой системы и процессора в каких то своих "пунктах", и учитывает это при построении плана.
Ага. Только они фиксированы и вшиты в оптимизатор.
В смысле, для любой дисковой подсистемы одно значение?
30 янв 12, 21:45    [11999686]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
alexeyvg
Гавриленко Сергей Алексеевич
пропущено...
Ага. Только они фиксированы и вшиты в оптимизатор.
В смысле, для любой дисковой подсистемы одно значение?
Именно.
30 янв 12, 21:49    [11999705]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
alexeyvg
Гавриленко Сергей Алексеевич
пропущено...
Ага. Только они фиксированы и вшиты в оптимизатор.
В смысле, для любой дисковой подсистемы одно значение?

Это ж не Oraцле с workload statistics... :(
30 янв 12, 22:20    [11999819]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Ray D
alexeyvg
пропущено...
В смысле, для любой дисковой подсистемы одно значение?

Это ж не Oraцле с workload statistics... :(
Да, слышал про эти оценки, но как то забыл, что они вшиты :-(
30 янв 12, 22:30    [11999870]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Mind
Оценка скорости дисков или фрагментации или еще чего подобного в момент построения плана уж очень ресурсоёмкая задача, которая при этом редко имеет практический смысл.
Как я понимаю, можно было иметь формулу для высчитывания "пунктов" для оптимизатора от этих редко меняющихся показателей, ну там перерасчёт по требованию (manual, event).
Mind
У Конора опять же по этому поводу было написано.
А есть что-то на русском и где поменьше воды? Для простых смертных.
31 янв 12, 19:57    [12007119]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Mind
Оценка скорости дисков или фрагментации или еще чего подобного в момент построения плана уж очень ресурсоёмкая задача, которая при этом редко имеет практический смысл.
Как я понимаю, можно было иметь формулу для высчитывания "пунктов" для оптимизатора от этих редко меняющихся показателей, ну там перерасчёт по требованию (manual, event).

Может и можно было, но неизвестно к каким результатам это бы привело. Так по крайней мере относительно стабильные планы, а если учитывать все-все-все, то будет еще больше вопросов и проблем с тем что вчера все работало, а сегодня тормозит и черт его знает что поменялось, а может серверу просто показалось, что вот этот диск стал работать медленне, потому что во время периодической (или запущенной вручную) оценки была существенная нагрузка на этот массив. Ну и как следствие все планы "поплыли".
Еще один немаловажный вопрос при оценке дисковой подсистемы. При построении плана никак не учитывается есть ли нужные данные в кэше или нет. А это становится очень критично, потому что даже если диск супер медленный, но все что нам нужно уже находится в памяти, то план не должен зависить от скорости дисков. А если через 2 минуты данные были вытеснены другим запросом, то тогда что? Перестраивать план? А физическая скорость считывания с диска. Если у нас данные фрагментированы по всему диску, то на скорости может сказатся весьма значительно. Как это учитывать? Все это выглядит весьма громоздким и неповоротливым, хотя, конечно я признаю, то что сейчас реализовано весьма далеко от идеала.

Mnior
Mind
У Конора опять же по этому поводу было написано.
А есть что-то на русском и где поменьше воды? Для простых смертных.

Так это же первоисточник, где еще про это читать? Я не знаю может быть SQL Server internals перевели на русский, там его раздел был про работу оптимизатора. А вообще на русском материала не много по этому вопросу, да и вообще по серверу, я уже не помню когда последний раз в гугле что-то по русски пытался найти.
31 янв 12, 22:35    [12007826]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mind
"изменения доступной памяти" - Это учитывает точно, Conor про это писал у себя в блоге. От количества доступной памяти зависит то насколько эффективно сервер может делать hash join и сортировку в памяти.
Что-то мне сомнительно что существующий план будет перекомпилирован в зависимости от доступной памяти, хотя может быть не лишено смысла, но насколько я помню, в таком случае, будет просто писать на диск... Дайте ссылку где вы это прочитали про рекомпилляцию от доступной памяти, а еще лучше репро.

VitLF
Вот, почтитайте whitepaper Plan Caching in SQL Server 2008, секцию "Causes of Recompilations"
31 янв 12, 22:39    [12007840]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SomewhereSomehow
хотя может быть не лишено смысла
Извиняюсь, лишено смысла.
31 янв 12, 22:56    [12007903]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SomewhereSomehow
Mind
"изменения доступной памяти" - Это учитывает точно, Conor про это писал у себя в блоге. От количества доступной памяти зависит то насколько эффективно сервер может делать hash join и сортировку в памяти.
Что-то мне сомнительно что существующий план будет перекомпилирован в зависимости от доступной памяти, хотя может быть не лишено смысла, но насколько я помню, в таком случае, будет просто писать на диск... Дайте ссылку где вы это прочитали про рекомпилляцию от доступной памяти, а еще лучше репро.

Извиняюсь, не совсем так. Не от доступной памяти, а от опции max server memory.
Ссылка все на того же Конора, где можно прочитать тоже по русски - не знаю.
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2011/09/30/conor-vs-max-server-memory.aspx
31 янв 12, 23:57    [12008211]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
Доступные ресурсы на выбор плана выполнения влияют хотя бы потому, что оптимизатор ограничен по времени на поиск оптимального плана выполнения. Меньше ресурсов - меньше планов будет рассмотрено, меньше вероятность, что поиск дойдет до действительно оптимального плана.
1 фев 12, 08:51    [12008810]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Mind
Mnior
пропущено...
Как я понимаю, можно было иметь формулу для высчитывания "пунктов" для оптимизатора от этих редко меняющихся показателей, ну там перерасчёт по требованию (manual, event).

Может и можно было, но неизвестно к каким результатам это бы привело. Так по крайней мере относительно стабильные планы, а если учитывать все-все-все, то будет еще больше вопросов и проблем с тем что вчера все работало, а сегодня тормозит и черт его знает что поменялось, а может серверу просто показалось, что вот этот диск стал работать медленне, потому что во время периодической (или запущенной вручную) оценки была существенная нагрузка на этот массив. Ну и как следствие все планы "поплыли".
Можно хотя бы дать возможность устанавливать это руками (например, указав тип рейда, тип дисков и количество шпинделей), а сиквел по этим данным устанавливал бы оценку скорости для оптимизатора.

Да, возможно ошибки были бы в 2-5 раз, но не в десятки-сотни, как сейчас.
1 фев 12, 08:53    [12008812]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mind
Извиняюсь, не совсем так. Не от доступной памяти, а от опции max server memory.
Ссылка все на того же Конора, где можно прочитать тоже по русски - не знаю.
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2011/09/30/conor-vs-max-server-memory.aspx
А, ну это совем другое дело.

Я имел ввиду такое поведение:
автор
Memory and spilling

Before a hash join begins execution, SQL Server tries to estimate how much memory it will need to build its hash table. We use the cardinality estimate for the size of the build input along with the expected average row size to estimate the memory requirement. To minimize the memory required by the hash join, we try to choose the smaller of the two tables as the build table. We then try to reserve this much memory to ensure that the hash join can successfully execute.

What happens if we grant the hash join less memory than it requests or if the estimate is too low? In these cases, the hash join may run out of memory during the build phase. If the hash join runs out of memory, it begins spilling a small percentage of the total hash table to disk (to a workfile in tempdb). The hash join keeps track of which “partitions” of the hash table are still in memory and which ones have been spilled to disk. As we read each new row from the build table, we check to see whether it hashes to an in-memory or an on-disk partition. If it hashes to an in-memory partition, we proceed normally. If it hashes to an on-disk partition, we write the row to disk. This process of running out of memory and spilling partitions to disk may repeat multiple times until the build phase is complete.
1 фев 12, 08:58    [12008826]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
alexeyvg
Mind
пропущено...

Может и можно было, но неизвестно к каким результатам это бы привело. Так по крайней мере относительно стабильные планы, а если учитывать все-все-все, то будет еще больше вопросов и проблем с тем что вчера все работало, а сегодня тормозит и черт его знает что поменялось, а может серверу просто показалось, что вот этот диск стал работать медленне, потому что во время периодической (или запущенной вручную) оценки была существенная нагрузка на этот массив. Ну и как следствие все планы "поплыли".
Можно хотя бы дать возможность устанавливать это руками (например, указав тип рейда, тип дисков и количество шпинделей), а сиквел по этим данным устанавливал бы оценку скорости для оптимизатора.

Да, возможно ошибки были бы в 2-5 раз, но не в десятки-сотни, как сейчас.

Ну указали мы тип рейда и прочее, а что делать с кэшем, как его учитывать? Данные с диска - одна скорость, данные из памяти другая, ну и толку от того что мы знаем какие у нас диски?
Ошибки в десятки-сотни раз чаще бывают связаны с неправильными оценками кардиналити из-за неправильной статистики, а не из-за того что сервер не знает как быстро сможет вычитывать данные с диска.
1 фев 12, 10:28    [12009195]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SomewhereSomehow
Mind
Извиняюсь, не совсем так. Не от доступной памяти, а от опции max server memory.
Ссылка все на того же Конора, где можно прочитать тоже по русски - не знаю.
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2011/09/30/conor-vs-max-server-memory.aspx
А, ну это совем другое дело.

Я имел ввиду такое поведение:
автор
Memory and spilling

Before a hash join begins execution, SQL Server tries to estimate how much memory it will need to build its hash table. We use the cardinality estimate for the size of the build input along with the expected average row size to estimate the memory requirement. To minimize the memory required by the hash join, we try to choose the smaller of the two tables as the build table. We then try to reserve this much memory to ensure that the hash join can successfully execute.

What happens if we grant the hash join less memory than it requests or if the estimate is too low? In these cases, the hash join may run out of memory during the build phase. If the hash join runs out of memory, it begins spilling a small percentage of the total hash table to disk (to a workfile in tempdb). The hash join keeps track of which “partitions” of the hash table are still in memory and which ones have been spilled to disk. As we read each new row from the build table, we check to see whether it hashes to an in-memory or an on-disk partition. If it hashes to an in-memory partition, we proceed normally. If it hashes to an on-disk partition, we write the row to disk. This process of running out of memory and spilling partitions to disk may repeat multiple times until the build phase is complete.

Если про это, то конечно, план не будет перекомпилирован если на сервере стало больше свободной памяти, чем в тот момент когда компилировался запрос. Если же вдруг доступной памяти стало меньше чем требуется запросу для выполнения, то такой запрос просто встанет в очередь ожидания, никакой перекомпиляции не будет.
1 фев 12, 10:35    [12009229]     Ответить | Цитировать Сообщить модератору
 Re: План исполнения запроса.  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
Mind
Ну указали мы тип рейда и прочее, а что делать с кэшем, как его учитывать? Данные с диска - одна скорость, данные из памяти другая, ну и толку от того что мы знаем какие у нас диски?

Ну это может сильно повлиять на применение операций, вызывающих random I/O.
Проблема в том, что если скуль начнет динамически подкручивать стоимости, то это может привести к нестабильности планов.
(то, с чем, насколько я помню, боролись в Oraцле).

C 2000-го, кстати, есть недокументированные dbcc -- setioweight, setcpuweight
1 фев 12, 11:56    [12009883]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить