Для
мониторинга производительности SQL Server одним из полезных
инструментов является Data Collector , который был
введен начиная с 2008
версии. Data Collector позволяет собирать разного рода
информацию о производительности системы из разных источников в единое хранилище
данных. Такими источниками могут быть SQLTrace, счетчики Performance Monitor и т.д. Например, можно ловить долго
выполнявшиеся запросы при помощи SQLTrace и сохранять
эту информацию в БД. Далее для
анализа и наглядного
представления можно строить различные отчеты, например в Reporting Serviсes:
Настройка хранилища данных Data_collection
Для
начала надо создать БД для Data_collection, например DATA_COLLECTION_DW
Далее
надо настроить хранилище данных для Data_collection:
Запустится
мастер Configure Management Data Warehouse Storage, интерфейс интуитивно понятный:
На
первом шаге надо указать сервер на котором расположится хранилище данных и название базы. На втором шаге настройка
безопасности – надо сопоставить пользователям и группам соответсвующие роли и на последнем
шаге завершение настройки:
Подготовка шаблона SQL SERVER PROFILER
Надо
подготовить шаблон трассы Profiler, который будет фиксировать запросы (Events=SQL:BatchCompleted) продолжительностью более 5 минут (Duration>=400000ms) и сохранить этот шаблон где-нибудь на диске, как показано на картинках ниже:
Примерно
такой скрипт шаблона должен получиться, далее
выполняем (Execute) на сервере этот скрипт
Теперь
сборщик готов, запускаем:
К сожалению, сама загрузка трассы Profiler
дублирует строки в БД, поэтому после каждого запуска сборщика следует запускать скрипт
удаления дубликатов trace_del_data_duplicates:
4 комм.:
На мой взгляд очень хороший инструмент. И полезный. И отчет наглядный. Это ведь настоящие данные? Теперь надо подумать, как этим пользоваться. Вот, например, Оля Тиханская запустила отчет в 6 утра, а построился он в 9. Три часа – ужас. Сразу напрашиваются вопросы и мысли: там время локальное или московское? Если локальное – надо наверное запрещать пользоваться отчетам в 6 утра. Если московское – то еще хуже, это раньше был быстрый отчет. Может быть, это был просто неудачный день, и надо посмотреть врамя выполнения этого отчета в динамике? Гуль, так можно? И, исходя из таких отчетов уже составлять списки на оптимизацию. То же самое касается супероборотки в Екате. Отчет более получаса строится.. В общем, надо это запускать как инструмент для оптимизации, Кирилл когда говорил о нашей статегии развития, по–моему это направление отдельно выделял.
Отвечаю на вопросы
1. Время мск, да это страшно :)
2. В динамике можно посмотреть, в этом самом отчете
Ссылку на отчет прописала на сайте Администраторам->Управление->Мониторинг тяжелых запросов
Подскажите, откуда сделана первая картинка?
И "Ссылку на отчет прописала на сайте Администраторам->Управление->Мониторинг тяжелых запросов" - где это?
Отправить комментарий