Более чем через год я хочу, чтобы все знали мой опыт и окончательный результат этого вопроса / темы.
Я начал создавать вещи самостоятельно. Вначале я следовал статье « Сбор и хранение исторических данных счетчиков производительности SQL Server с CMV » Тима Форда, чтобы что-то поднять и дополнить этими данными, которые я хотел собрать. Поэтому один раз в день я запускаю несколько хранимых процедур на каждом сервере Sql, которые собирают определенную информацию из DMV и сохраняют результаты на локальном сервере внутри базы данных. Это включает в себя использование индекса, отсутствующие индексы, определенные записи журнала, такие как автостраковка, настройки сервера, настройки базы данных приложения, фрагментация, выполнение задания, информация журнала транзакций, информация о файле, статистика ожидания и многое другое.
Кроме того, я добавил в этот репозиторий результаты регулярного выполнения sp_blitz Брента Озара, чтобы собрать дополнительные ценные указания для работы, улучшения и составления отчетов.
Все данные впоследствии собираются оттуда на выделенный сервер мониторинга Sql, и таким образом я создаю объединенное хранилище для информации о производительности всех моих серверов и использую ее в качестве базы для расследования и составления отчетов.
Затем я создал таблицы Excel, а также отчеты, используя службы отчетов для анализа и интерпретации. Некоторые образцы:
Также я настроил мониторинг некоторых счетчиков производительности с помощью TYPEPERF, вдохновленного статьей Федора Георгиева « Сбор данных о производительности в таблицу SQL Server ».
Из моего экземпляра SQL Monitoring я запускаю typeperf и собираю настраиваемое количество выборок с настраиваемым интервалом выборки и сохраняю результаты в моей базе данных центрального мониторинга.
Это позволяет мне наблюдать долгосрочные значения производительности, пример:
Через некоторое время использования этого для сбора исходной информации выяснилось, что на поиск неудачных заданий, процедур устранения ошибок (например, в случае отключения БД в автономном режиме) приходится потратить довольно много работ по обслуживанию. не удалось выполнить сценарии), поддерживая настройки после замены сервера ...
Кроме того, база данных, собирающая все записи, нуждается в техническом обслуживании и настройке производительности, поэтому для обеспечения полезности этих данных требуется дополнительная работа ...
Что в конечном итоге полностью отсутствует, так это способность смотреть на то, что происходит вживую. В лучшем случае я смогу рассказать, что, возможно, происходило на следующий день после запуска сборщиков данных. Также все детали отсутствуют. У меня нет доступа к графикам взаимоблокировок, я не могу посмотреть планы запросов, которые выполнялись в подозрительном периоде ....
Все это заставило меня поручить руководству тратить деньги на профессиональное решение, которое я не могу создать самостоятельно.
Окончательный выбор состоял в том, чтобы купить SentryOne, потому что по сравнению с другими он убедителен и предоставляет много информации, необходимой для определения наших болевых точек.
В качестве заключительного заключения я бы посоветовал всем, кто ищет ответы на подобные вопросы, не пытаться создавать вещи самостоятельно, если у вас нет небольшой и в основном здоровой среды. Если у вас есть пара систем и много проблем, лучше немедленно обратиться за профессиональным решением и использовать помощь поставщика в решении ваших проблем, а не тратить много времени и денег на создание чего-то менее полезного. Однако этот маршрут все еще был очень интересным и заставил меня многому научиться, я не хочу пропустить.
Я надеюсь, что вы найдете это полезным, как только вы столкнулись с этой веткой вопросов.
РЕДАКТИРОВАТЬ 20 апреля 2017 г .:
Брент Озар недавно опубликовал на Facebook следующую статью, в которой рассказывается, что подобный подход используется командой SQL Tiger: https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining. -reports-развязали-для-предприятия-контроля /