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

Twitter RSS
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 или перекомпилировать процедуру каким-либо другим способом. Вы должны сохранить медленный план, чтобы потом изучить его, и найти для каких значений параметров был построен плохой план. Это тема данной главы.

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

 
formats

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

Давненько я хотел написать что-нибудь на эту тему. Однако, пока я собирался с мыслями и силами, наткнулся на уже написанную статью Slow in the Application, Fast in SSMS? Understanding Performance Mysteries Erland-а Sommarskog, которая исчерпывающе отвечает на поставленный вопрос. Так что мне осталось только представить перевод этой статьи, который я для удобства разделил на три части.

Введение

Когда я просматриваю различные форумы по SQL Server, я часто вижу вопросы от глубоко озадаченных пользователей. Они нашли медленный запрос или процедуру в своем приложении. Переместили этот пакет из своего приложения в SQL Server Management Studio (SSMS), чтобы проанализировать и обнаружили, что ответ от сервера приходит мгновенно. С этого момента они начинают думать что SQL Server это нечто магическое. Похожая загадка происходит и в случае если разработчик извлекает запрос из своей хранимой процедуры, чтобы выполнить его отдельно, но обнаруживает что он выполняется гораздо быстрее — или гораздо медленнее — чем внутри хранимой процедуры.
Нет, SQL Server это не магия. Но если у вас нет хорошего понимания того как SQL Server компилирует запросы и поддерживает кэш планов выполнения, так может показаться. Кроме того есть некоторые неудачные комбинации различных настроек по умолчанию в некоторых средах. В этой статье я постараюсь разъяснить, почему вы получаете такое, казалось бы, не согласующееся поведение. Я объясню, как sql server компилирует хранимую процедуру, что такое прослушивание параметров (parameter sniffing) и почему оно является важной частью уравнения в большинстве сбивающих с толку ситуаций. Я объясню, как sql server использует кэш, и почему в кэше может быть несколько записей для одной процедуры. Стоит только копнуть глубже, и вы поймете, как получается так, что запрос в SSMS выполняется гораздо быстрее.
Читать дальше…

 
formats

Выбор полей для кластерного индекса

Существуют разные точки зрения на тему, какое поле лучше всего подходит в качестве кластерного индекса для таблицы. В частности такое «кластерный индекс должен удовлетворять запросам для выбора большого числа строк, желательно что бы это не было поле identity, т.к. при такой организации могут возникать hotspot при вставке, а выбор по диапазону identity явление очень редкое».
Так же есть мнения, что такой подход уже давно не актуален в новых версиях, а выбор в качестве кластерного индекса например поля guid — ведет к фрагментации. Для себя я выработал некоторое мнение по этому вопросу. А недавно наткнулся на интересную статью по выбору поля для кластерного индекса в блоге Kimberly L. Tripp, которая еще больше подтвердила некоторые мои мысли относительно этого.
Хотя статья не новая, но мне кажется она может быть полезна людям которые задавали или задают себе этот вопрос. По этому, привожу свою версию перевода статьи.

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

 
formats

Некоторые случаи необрабатываемые блоком try/catch

Возможно, не все знают, что в t-sql конструкция try catch обрабатывает не все ошибки.
Это поведение хорошо документировано, но может стать сюрпризом для людей привыкших работать с классическим try/catch в объектно-ориентированных языках.
Подробно это описано в документации TRY…CATCH (Transact-SQL), Использование конструкции TRY…CATCH в языке Transact-SQL — я же просто приведу некоторые примеры, на которые наталкивался сам.

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

 
Теги:, ,
formats

Можно ли отсортировать результаты во вью?

Ответ: можно, но это не правильно, т.к. недокументировано.
Согласно документации предложение order by запрещено во вью (если не указан оператор top, но и тогда порядок не гарантируется) и если вам нужно получить отсортированный результат из вью — то предложение order by необходимо указывать в запросе к этому вью.
Тем не менее, отсортированные данные получить все-таки можно, т.к. «как правило» (чисто эмпирически) top совместно с order by приводит к сортировке в плане (однако т.к. это не документировано само собой нет гарантии, что так будет всегда).
Рассмотрим некоторые из способов создания такой сортировки.

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