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

Twitter RSS
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)

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

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

 
formats

Оптимизатор (ч.1): Введение, Optimization: Simplification

Введение

В этом разделе:
— обзор;
— упрощение, исключение противоречий и лишних соединений;
— просмотр дерева логических операций;

В данной заметке рассматриваются некоторые механизмы работы оптимизатора. Она будет интересна тем, кто хочет больше узнать о процессе преобразования запроса в план запроса, который и будет передан серверу на выполнение.
Многие средства, используемые в заметке — недокументированны, по этому, ни в коем случае не рекомендуется применять их на «боевых» серверах. Также, если вы хотите выполнять приведенные в заметке запросы, то рекомендуется версия сервера для экспериментов «Microsoft SQL Server 2008 R2 (RTM) — 10.50.1600», иначе результат может отличаться.
Итак, приступим.

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

 
formats

Дополнительные чтения в nested loops

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

 

 

 

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

 
formats

Нужно ли бороться с фрагментацией в таблице-куче

Недавно, на одном из форумов был озвучен интересный вопрос. Есть сильно фрагментированная таблица (фрагментация более 80%), без кластерного индекса. Вопрос заключается в том, что нужно ли пытаться бороться с фрагментацией, например, создавая и удаляя для этого кластерный индекс. Влияет ли фрагментация на то, как используется стратегия чтения read-ahead.

 

 

 

В этой заметке я постарался исследовать этот вопрос. Заметка состоит из следующих частей:
— Немного теории о структурах данных – основные понятия
— Немного практики в изучении структур данных
— Что такое фрагментация и какая она бывает
— Фрагментация небольших таблиц
— Что такое read-ahead
— Фрагментация экстентов – эксперимент
— Полезные ссылки

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

 
formats

Копирование данных из связанных таблиц при помощи MERGE

Периодически в работе возникают задачи копирования данных из связанных таблиц. Например, копировать все заказы и соответствующие позиции заказа одного клиента другому клиенту. Для решения такой задачи без циклов в SQL Server 2008 можно использовать инструкцию MERGE.

 

 

 

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

 
Теги:, ,
formats

Entity Framework Code First — попытка разобраться как работает эта магия

В данной заметке я постарался рассмотреть Entity Framework и подход к проектированию Code First с точки зрения человека, который не имел дело с ORM и Entity Framework и пытается подробно разобраться, как это все работает.

При работе с БД всегда возникает вопрос, как организовать эту самую работу и где размещать бизнес логику. Способов много, но один умный дядька собрал все воедино, классифицировал, углубил и обострил — и выпустил книгу Архитектура корпоративных программных приложений. С тех пор, в холиварах по размещению бизнес логики появились конкретные термины, в частности два наиболее распространенных из них: Transaction Script (логика в процедурах) и Domain Model (логика в объектах модели). Не будем здесь обсуждать, какой поход лучше, только скажу, что мое мнение — обсуждать инструмент в отрыве от задачи бессмысленно.

До недавних пор почти всю логику мне приходилось писать в хранимых процедурах на сервере, но настало время посмотреть более подробно, что же твориться во «вражеском» лагере. А творятся там интересные вещи, работа ведется с объектами, а объекты стыкуются с БД при помощи средств объектно-реляционного отображения (Object Relational Mapping — ORM). Одной из систем ORM является Entity Framework (EF) от Microsoft, именно ее я выбрал жертвой своих бесчеловечных экспериментов.

Прежде чем продолжить, хочу сказать, что, хотя EF довольно молод, по нему уже есть куча замечательного материала, руководств и tutorial-ов. В частности, рекомендую к ознакомлению руководство по созданию модели EF на сайте asp.net (eng), которое, кстати, так же доступно в виде pdf или его русскую адаптацию в блоге Владимира Юнева. Если вы преследуете цель максимально быстро начать использовать EF, не вдаваясь в подробности его работы, то смело переходите по указанным выше ссылкам, а к этой статье вернетесь позже, если будет такой интерес. Если же вам, как и мне, всегда интересно, что скрывается за тем, когда несколько строк кода приводят к созданию запросов, таблиц и целой БД — тогда давайте разбираться дальше вместе.

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

 
formats

Медленно в приложении, быстро в SSMS (часть 3)

Динамический SQL

До настоящего времени, мы посмотрели только на хранимые процедуры, и для них, наиболее вероятная причина для разной производительности в SSMS и приложении это разные настройки SET ARITHABORT. Если у вас есть приложение, которое не использует хранимые процедуры, а генерирует запросы на клиенте, или на каком-либо промежуточном слое, есть еще несколько причин, почему вы можете получить новую запись в кэше и соответственно возможно новый план, выполняя тот же самый запрос из SSMS. В этой главе мы посмотрим на эти возможные причины. Мы также посмотрим на некоторые решения для исправления ситуации с проблемным прослушиванием параметров, которые наиболее характерны для динамического SQL.

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

 
formats

Медленно в приложении, быстро в SSMS (часть 2)

Собираем информацию для решения проблем прослушивания параметров

Вы уже узнали, как может получиться так, что хранимая процедура, которая выполняется в приложении медленно, при таком же вызове из SQL Server Management Studio выполняется быстро: из-за разных настроек ARITHABORT вы получаете разные записи в кэше, а т.к. SQL Server использует прослушивание параметров, вы можете получать разные планы выполнения.

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

EXEC sp_recompile ваша_проблемная_процедура

Как мы видели, это удалит план процедуры из кэша, и при ее следующем вызове, будет построен новый план. Если проблема больше не проявится, можно считать дело закрытым.

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

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