SomewhereSomehow's Notes

Фильтр по тегу: performance


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

Optimization: Full Optimization: Search 1

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

читать дальше...
добавлено: 27 мар 12 просмотры: 2401, комментарии: 11



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

Optimization: Full Optimization: Search 0

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

читать дальше...
добавлено: 27 мар 12 просмотры: 2089, комментарии: 3



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

Optimization: Trivial Plan Optimization

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


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



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

Введение

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


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



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

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



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

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

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



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

Как SQL Server компилирует динамический SQL

Оставим тему прослушивания параметров, и вернемся обратно к теме данной статьи: почему запрос может долго выполняться из приложения, но быстро из SQL Server Management Studio. До настоящего времени, мы посмотрели только на хранимые процедуры, и для них, наиболее вероятная причина такого поведения разные настройки SET ARITHABORT. Если у вас есть приложение, которое не использует хранимые процедуры, а генерирует запросы на клиенте, или на каком-либо промежуточном слое, есть еще несколько причин, почему вы можете получить новую запись в кэше и соответственно возможно новый план, выполняя тот же самый запрос из SSMS.
читать дальше...
добавлено: 29 июн 11 просмотры: 4220, комментарии: 3



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

Собираем информацию для решения проблем прослушивания параметров
Вы уже узнали, как может получиться так, что хранимая процедура, которая выполняется в приложении медленно, при таком же вызове из SQL Server Management Studio выполняется быстро: из-за разных настроек ARITHABORT вы получаете разные записи в кэше, а т.к. SQL Server использует прослушивание параметров, вы можете получать разные планы выполнения.
И хотя разгадка этой проблемы теперь получена, основная проблема еще остается: как подойти к проблеме производительности?
читать дальше...
добавлено: 29 июн 11 просмотры: 4089, комментарии: 0



Медленно в приложении, быстро в 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 выполняется гораздо быстрее.
читать дальше...
добавлено: 29 июн 11 просмотры: 12710, комментарии: 2



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

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