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

Откуда: СПб
Сообщений: 30
Здравствуйте.
Подскажите, есть ли параметр в MS SQL, отвечающий за время, которое отводится серверу для выбора оптимального плана выполнения запроса?
И вообще, какими параметрами работы оптимизатора можно управлять?
13 мар 14, 16:35    [15718841]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
bib,

Лучше делать правильные структуры, индексы, выполнять рекомендации по обновлению статистик и грамотно писать запросы. В таком случае не придется ничего настраивать. В особо сложных случаях, есть документированный механизм воздействия на оптимизатор посредством подсказок и руководств планов.

Прочие параметры конечно есть, но они не документированы и их использовать на боевых системах нельзя.

Если у вас есть какой-то проблемный план, то выкладывайте его сюда в виде файла .sqlplan (действительный, а не оценочный), можно будет посмотреть.
13 мар 14, 16:49    [15718953]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Вообще-то сабж имеет под собой основание.

Для одного-двух запросов можно и поиграться, с подсказками.
Но если для семейства запросов, к примеру если разработка вышла за допустимые пределы скуля - то ахтунг.

Притом я бы сказал, что иногда хотелось увеличить время компиляции - "ну скуль, ну подумай ещё чуть-чуть, будь отличником".
Главное при этом зафиксировать планы.

А всё от того что компилятор имеет фатальный недостаток ...
14 мар 14, 03:30    [15721444]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8350
Если совсем плохо дело, то можно просто скопипастить запросы и использовать, например, хинт OPTIMIZED FOR или, как уже писали, использовать различные руководства плана для различного набора параметров.
14 мар 14, 12:56    [15723272]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mnior
Но если для семейства запросов ...
Владислав Колосов, В случае к примеру динамического программирования точечный подход не прокатит.
14 мар 14, 19:52    [15726734]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Время отводимое на оптимизацию не измеряется временем.
Оно измеряется количеством операций оптимизации отведенным на данный запрос. Т.е. timeout это не время.

Вот я давал объяснение на тему:
изменение плана со временем

Еще, есть две мои заметки на эту тему:
Оптимизатор без границ (ч.1)
Оптимизатор без границ (ч.2)
должна была быть еще часть три, и она есть, но я ее не публикую, т.к. ну нафиг =)
14 мар 14, 20:13    [15726842]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Короче, если лень читать, увеличение таймаута врядли приведет к значимому увеличению эффективности плпнп. А время на компиляцию плана вы потратите гораздо больше. Так что если хотите положить сервер по CPU - вперед - отключайте таймаут. Если вы экспериментируете то другое дело. Обычно, есть более легитимные способы побороть неэффективный план, чем заставить оптимизатор дольше исследовать.

Если кто-то приведет пример, когда это не так! Это будет круто! Все вместе запостим его на коннект и расплюемся с недокументированностью =)
14 мар 14, 20:17    [15726854]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Для одного-двух запросов можно и поиграться, с подсказками.
Но если для семейства запросов, к примеру если разработка вышла за допустимые пределы скуля - то ахтунг.

Притом я бы сказал, что иногда хотелось увеличить время компиляции - "ну скуль, ну подумай ещё чуть-чуть, будь отличником".
О да, я уже даже вижу как это будет работать:
1. Горе архитектор делает кривой дизайн базы.
2. Горе программисты пишут корявые запросы.
3. Горе DBA "забывают" что нужно обновлять статистики и прочее.
4. При увеличении объема данных все это начинает дико тормозить.

И тут находится гений и предлагает для всех запросов сразу (ну а че заморачиваться то) включить супер-фичу - "Нам думать лень, сервер ты подумай за нас". Как итог - всё те же медленные запросы, только теперь еще и CPU зашкаливает. Вывод: SQL Server тупой, давайте перепишем все под MongoDB.

Учитывая, что в 90% случаев план кривой из-за неправильных эстимейтов, которые возникают по причине кривизны/ограниченности статистик и/или как результат parameter sniffing, то опция "подумай подольше" в большинстве случаев не имеет смысла. Если данные для анализа неверные, то можно хоть год план строить, лучше он от этого не станет.
В отдельных единичных случаях может это и имеет какой то смысл, но не для семейства запросов, ибо цель не оправдывает средства.
14 мар 14, 20:32    [15726931]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mind,
Красавчег! =)

Я не уверен что этоило адресовать Mnior-у, он вроде в теме. Но в целом полностью поддерживаю.

Собственно Mind, эмоционально, но высказал также и мою точку зрения, она же и совпадает с официальной от МС, она же (как ни пародоксально) с реальностью.

Несогласных ждем с репро где ни один из легитимных способов, кроме продолжить оптимизацию, не работает (кстати, у меня есть такое репро, но оно не релевантно реальности). Если будут такие репро - это круто! Будем размещать на коннекте, будут править.
14 мар 14, 20:50    [15726998]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL. Изменение времени, отводимого на выбор оптимального плана выполнения запроса.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mind
И тут находится гений и предлагает для всех запросов сразу (ну а че заморачиваться то) включить супер-фичу - "Нам думать лень, сервер ты подумай за нас".
А разве SQL сам по себе не воплощение этой идеи?!
Или вы хотите сказать что процессор Intel понимает SQL команды?
В том-то и дело, что пишем мы на языке близкий к человеческому, и пишем мы кстати не курсоры на оракакле, которые, как мы знаем работают намного резвее у них, а именно запросы - полностью перекладывая оптимизацию на сервер.
И если вы утверждаете что проблема только в плохом дизайне, и все возможные в природе запросы (в кошерно задизайненых базах) компилируется не более за N шагов (установленное M$) - то вы лукавите. Задачи разнообразны по своей природе.

Mind
Как итог - всё те же медленные запросы, только теперь еще и CPU зашкаливает.
Тут вы передёргиваете.
Вот есть у плана такой показатель: "Reason for Early Termination of Statement".
И если он будет "Good Enough Plan Found" - то не важно, поставите ли вы флаг 8780 или нет. И CPU не станет загружен больше ни на такт.
OPTION(QUERYTRACEON 8780)

А вот если результат был "Timeout", то да, CPU будет дальше надрываться.
А то что найдёт ли он лучше план для всех запросов или для большинства - это второе.
Главное что этот показатель не линеен и однозначен (плох), как вы пишите.

Mnior
иногда хотелось увеличить время компиляции
Mind, вы банально не поняли контекст разговора, ну чтобы не придирались, контекст что я лично имел ввиду.
Процедура/запрос не компилится каждый раз, готовый план может быть исполнен тысячи и сотни тысяч раз, т.е. полученный план за счёт лишних тактов CPU может с лихвой окупится. А с другой стороны, стоимость поиска плана на фоне количества его использований нивелируется. И эта мысль не была озвучена в заметках SomewhereSomehow, более того стоимость поиска плана есть главный аргумент в приведённом им примере.

Если бы ТС спрашивал "А может стоит поставить флаг 8780 для всего сервера по умолчанию", то излишнее родительское опекунство имело бы смысл, но вопрос был задан довольно профессионально. IMXO
С другой стороны, люди не на столько глупы, чтобы ставить оценку "MS SQL говно и тормоз", после того как сами же довольно нетривиально повесили этот флаг на сервер.

Так что если у вас есть время, ищите планы с "Timeout"-ами и ставьте флаг 8780 и не бойтесь экспериментировать. И если убедились что это хорошо, то не бойтесь это применять.

А у гуру SomewhereSomehow лучше спросить:
Как выявлять запросы с "Reason For Early Termination: Time Out"?
Как собрать статистику по этому показателю? (количество выполнений с такими планами к общему числу)

И каков этот показатель на ваших серверах?
2 май 14, 01:23    [15963089]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить