Продолжаем отключать внутренние пороги оптимизатора. В первой части были приведены общие теоретические сведения (на которые я буду ссылаться, по этому, рекомендую их просмотреть, если еще не успели), а так же представлен флаг трассировки 8780 который устанавливает timeout в очень большое число, фактически отключая его. Осталось несколько других механизмов управляющих тем, когда происходит оптимизация и
Оптимизатор без границ (ч.1)
На недавнем мероприятии SQL Saturday 178, мне задали вопрос, можно ли сделать так, чтобы оптимизатор не прекращал оптимизацию, когда посчитает что уже нашел хороший план или наступит таймаут, а исследовал все альтернативы. Я ответил, что документированных средств нет, либо я о таких не знаю. И это действительно так, однако, возможно есть какие-то недокументированные флаги трассировки,
SQL Saturday #178 Moscow – Inside Query Optimizer
Всем добрый день, как и обещал, выкладываю материалы своего доклада на SQL Saturday. Выражаю благодарность всем организаторам, на мой взгляд все прошло хорошо (несмотря на проверку пожарной безопасности =)). К сожалению, не смог присутствовать на всех докладах, на которых хотелось бы, но там где присутствовал — было здорово. И самое главное, спасибо всем пришедшим, без
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.
Ошибка вычисления селективности для предикатов с isnumeric
Недавно на одном из форумов был задан вопрос о том, почему при добавлении в запрос условия isnumeric(column)=0, запрос начинает выполняться очень медленно. Изучение этой ситуации привело к интересным результатам.
RowGoal и неравномерное распределенных данных
На написание этой заметки меня подвиг доклад Алексея Эксаревского на 24 hours of PASS про наиболее часты причины ошибок в оценке кардинальности. Те, кто не видел этот доклад могут ознакомиться с ним на techdays. Алексей рассказывает о возможных причинах неправильных оценок кардинальности (или количества строк), из-за чего оптимизатор выбирает неудачный план запроса. Наиболее интересным и
Оптимизатор (недокументированное): Отключить правила преобразования в отдельном запросе
Многие, кто интересуется внутренним устройством оптимизатора, уже наверняка знают, что такое правила преобразования и то, что их можно отключить в сессии при помощи dbcc ruleoff/ruleon. В этой короткой заметке мы посмотрим на недокументированный хинт, который позволяет отключать правила преобразования в отдельно взятом запросе. Прим: Те, кто не знают про правила преобразования, но интересуются, могут обратиться
Оптимизатор (ч.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), и сразу перейти к этой фазе, если в запросе менее трех таблиц. Также эта фаза примечательна
Оптимизатор (ч.3): Optimization: Full Optimization: Search 0
Optimization: Full Optimization: Search 0 В этом разделе: — определение стадий оптимизации, которые проходит запрос; — структура для поиска альтенатив memo; — оператор Apply lookup в nested loops join; — оценки и вычисления селективности запроса с несколькими предикатами; — стоимость операторов; — Rebind, Rewind, RowGoal; — просмотр начального и конечного memo; — выходное дерево физических
Оптимизатор (ч.2): Optimization: Trivial Plan Optimization
Optimization: Trivial Plan Optimization В этом разделе: — применение правил преобразования; — особенности стадии trivial plan; — почему загружается статистика; — как пропустить фазу поиска тривиального плана (upd) Итак, мы получили наше упрощенное дерево. Но как оптимизатор догадался его упростить, что именно сделал. Разберемся. Для начала, немного теории.