Эта процедура описана в электронной документации в разделе, посвящённом производительности запроса. Её назначение сводится к тому, что бы, цитирую: Эта процедура может использоваться, когда нельзя или не нужно напрямую менять текст запроса. Руководства планов полезны, когда небольшое подмножество запросов в приложении базы данных стороннего разработчика выполняются не так, как ожидается.
Давайте рассмотрим упрощённый пример организации уведомлений о тупиковой блокировке и сделаем так, чтобы по электронной почте можно было получить письмо с графом блокировок.
Идея
взята из статьи: Using
dtutil to copy SSIS packages stored in SQL Server
Дополнительная
информация тут: Программа
dtutil
Суть демонстрации, создать список команд для копирования пакетов. Команды, после анализа кода, нужно скопировать через буфер обмена в окно запроса и выполнить.
|
SELECT instance_name AS
[Старый функционал] |
С помощью Power Shell и нового в SQL Server 2008 типа шага в заданиях по расписанию, который позволяет запускать под управлением SQL Server Agent сценарии Power Shell, теперь можно получить абсолютно любые счётчики производительности. Причём, сделать это можно как для локального, так и удалённого в сети сервера. А получение сведений о счётчиках посредством WMI избавляет от необходимости агрегации сырых значений, что делает этот метод простым и понятным.
Авторы этого учебного курса
считают, что соотношение суммарных ожиданий процессоров и ввода-вывода можно
использовать для того, чтобы определить, кто из них из-за кого простаивает.
Впрочем, вот выдержка из этой замечательной книги, со страницы 400:
Одной из самых сложных задач, с которыми сталкиваются разработчики баз данных, является прогнозирование поведения приложения в реальных условиях. Чтобы иметь точное представление о характеристиках производительности приложения, разработчик должен знать конкретную причину любого состояния ожидания, которое возникает во время выполнения приложения. На самом общем уровне состояния ожидания можно разбить на две категории: ожидание сигнала и ожидание ресурса. В SQL Server ожидание сигнала происходит, когда планировщик ждет процессор, чтобы запланировать задачу, а ожидание ресурса возникает, когда задача получила время процессора, но находится в ожидании ресурсов диска или памяти. При исследовании состояний ожидания в приложении нужно иметь в виду следующее. Если отношение времени ожидания сигнала ко времени ожидания ресурса велико (т.е. если состояний ожидания сигнала значительно больше, чем состояний ожидания ресурса), это может служить показателем неэффективного использования процессора. Если же велик коэффициент отношения времени ожидания ресурса ко времени ожидания сигнала, это может указывать на неэффективное использование ресурсов диска. Приступая к оценке производительности приложения, разработчики должны понимать, какой из типов ожидания преобладает. К счастью, SQLOS предоставляет "окно" в систему, достаточно прозрачное для того, чтобы разработчики могли использовать его для ответа на этот вопрос.
Разработчики SQL Server 2008
позаботились о том, чтобы предоставить нам с вами в распоряжение некую «палочку
– выручалочку», которая призвана как раз снизить затраты на вставку, путём её
не полного журналирования. Для этого предлагается задействовать на серверах
флаг трассировки 610, который по моим наблюдениям действительно может немного
облегчить вставку. Флаг, и его побочные эффекты, подробно описан тут: The Data Loading Performance Guide
Ещё одна мера, в дополнение к
включению флага трассировки 610, описана в документе вендора: SQL Server Best Practices Article.
Там, среди прочего, подробно описано исследование того, что будет эффективней,
вставка в таблицу с единственным некластеризованным индексом, или вставка в
таблицу с единственным кластеризованным индексом. Кластеризация данных может
дать выигрыш на вставке до 3%.
Вот такие маленькие хитрости
попались мне на глаза в документации Майкрософт. Быть может, кто-нибудь из
читателей этого блога поделиться в комментариях своими маленькими хитростями?
В тему:
