Заметки Дмитрия Пилюгина о Microsoft SQL Server 

Twitter RSS
formats

Оптимизатор без границ (ч.2)


Продолжаем отключать внутренние пороги оптимизатора.

В первой части были приведены общие теоретические сведения (на которые я буду ссылаться, по этому, рекомендую их просмотреть, если еще не успели), а так же представлен флаг трассировки 8780 который устанавливает timeout в очень большое число, фактически отключая его.

 
Осталось несколько других механизмов управляющих тем, когда происходит оптимизация и какие учитываются альтернативы:

  • Timeout
  • Cost Based Pruning Factor
  • Discarding


 
Читать дальше…

 
formats

Оптимизатор без границ (ч.1)

На недавнем мероприятии SQL Saturday 178, мне задали вопрос, можно ли сделать так, чтобы оптимизатор не прекращал оптимизацию, когда посчитает что уже нашел хороший план или наступит таймаут, а исследовал все альтернативы. Я ответил, что документированных средств нет, либо я о таких не знаю. И это действительно так, однако, возможно есть какие-то недокументированные флаги трассировки, которыми можно влиять на этот процесс. Я решил провести небольшое исследование и в этой заметке расскажу о его результатах.

Забегая вперед, сразу сообщу об итогах исследования, для тех кому не важны технические подробности, а важны выводы. Оказывается, действительно можно сделать так, чтобы оптимизатор продолжал поиски «до упора», но вероятность, что он действительно найдет гораздо более удачный план невелика. Это логично, иначе, если бы оптимизатор очень часто «недооптимизировал» запросы, прекращая поиски раньше положенного, то следовало бы поменять механизм определения того самого момента, когда считается, что искать план дальше не имеет смысла. Между тем, оптимизатор довольно неплохо справляется со своей задачей, а когда не справляется, причина очень часто кроется не в самом оптимизаторе, а в том с чем ему приходится работать (неактуальная статистика, плохо написанный код и т.д.). Хотя, ради справедливости, стоит сказать, что бывают случаи, когда причина в самом оптимизаторе.

Далее, я расскажу о том, как заставить оптимизатор отбросить ограничения и продолжать оптимизацию до конца.

Читать дальше…

 
Теги:, , ,
formats

SQL Saturday #178 Moscow – Inside Query Optimizer

Всем добрый день, как и обещал, выкладываю материалы своего доклада на SQL Saturday.
Выражаю благодарность всем организаторам, на мой взгляд все прошло хорошо (несмотря на проверку пожарной безопасности =)).
К сожалению, не смог присутствовать на всех докладах, на которых хотелось бы, но там где присутствовал — было здорово.
И самое главное, спасибо всем пришедшим, без вас ничего бы не получилось!
 
SQLSaturday178 — Inside Query Optimizer (~ 900 KB)

 
formats

isnumeric selectivity estimation bug (en)

Some time ago on one of the forums there was a question, about why adding to the query where clause a condition «isnumeric(column)=0», makes query very slow.
I did some investigations and that lead me to some interesting results.
Читать дальше…

 
formats

Ошибка вычисления селективности для предикатов с isnumeric

Недавно на одном из форумов был задан вопрос о том, почему при добавлении в запрос условия isnumeric(column)=0, запрос начинает выполняться очень медленно. Изучение этой ситуации привело к интересным результатам.
Читать дальше…

 
formats

RowGoal и неравномерное распределенных данных

На написание этой заметки меня подвиг доклад Алексея Эксаревского на 24 hours of PASS про наиболее часты причины ошибок в оценке кардинальности. Те, кто не видел этот доклад могут ознакомиться с ним на techdays.

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

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

RowGoal – это механизм оптимизатора, который позволяет основываясь на заранее известном числе строк, которые необходимо получить (например в запросе есть предложение Top N), ограничить число строк для обработки в более ранних операторах. Казалось бы, если мы заранее знаем число строк, то это позволит выбрать лучший план. И, как правило, это так, однако, при некотором особенном распределении данных, этот механизм может мешать.

Рассмотрим механику более подробно.

Читать дальше…

 
formats

Оптимизатор (недокументированное): Отключить правила преобразования в отдельном запросе

Многие, кто интересуется внутренним устройством оптимизатора, уже наверняка знают, что такое правила преобразования и то, что их можно отключить в сессии при помощи dbcc ruleoff/ruleon. В этой короткой заметке мы посмотрим на недокументированный хинт, который позволяет отключать правила преобразования в отдельно взятом запросе.

Прим:
Те, кто не знают про правила преобразования, но интересуются, могут обратиться к моему предыдущему циклу заметок, части Оптимизатор (ч.2): Optimization: Trivial Plan Optimization.  Если вкратце, речь идет о том, что оптимизатор в процессе преобразования запроса в план, использует правила преобразования. Их довольно много, набор изменяется, некоторые правила удаляются, расширяются и неизменно добавляются, в целом количество увеличивается от версии к версии. Получить их можно запросив представление sys.dm_exec_query_transformation_stats.

Читать дальше…

 
formats

Оптимизатор (ч.4): Optimization: Full Optimization: Search 1

Optimization: Full Optimization: Search 1

В данном разделе:
— update statistics with row_count, page_count;
— преобразования memo;
— параллельный план;

 

Данная фаза, называется также Quick Plan. Как мы уже говорили, запросы могут миновать стадию Transaction Processing (search 0), и сразу перейти к этой фазе, если в запросе менее трех таблиц.
Также эта фаза примечательна тем, что на ней осуществляется поиск параллельного плана.

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

Читать дальше…

 
formats

Оптимизатор (ч.3): Optimization: Full Optimization: Search 0

Optimization: Full Optimization: Search 0

В этом разделе:
— определение стадий оптимизации, которые проходит запрос;
— структура для поиска альтенатив memo;
— оператор Apply lookup в nested loops join;
— оценки и вычисления селективности запроса с несколькими предикатами;
— стоимость операторов;
— Rebind, Rewind, RowGoal;
— просмотр начального и конечного memo;
— выходное дерево физических операторов;

Читать дальше…

 
formats

Оптимизатор (ч.2): Optimization: Trivial Plan Optimization

Optimization: Trivial Plan Optimization

В этом разделе:
— применение правил преобразования;
— особенности стадии trivial plan;
— почему загружается статистика;
— как пропустить фазу поиска тривиального плана (upd)

Итак, мы получили наше упрощенное дерево. Но как оптимизатор догадался его упростить, что именно сделал. Разберемся. Для начала, немного теории.

Читать дальше…