Comments 12
Здравствуйте. Интересная статья, отличная работа. Делал похожее решение, но без автоматического запуска, только ручной запуск и анализ.
В своём решении не стал в трассировку включать события с кодом 13 SQL:BatchStarting, в них не нашел полезной информации для профилирования.
Но включил:
162. User Error Message148. Deadlock Graph
Особенностью https://habrahabr.ru/company/npo-comp/blog/243587/ является группировка запросов по текстам, самодельная. Позже научился группировать по query_stats.query_hash, как сделано в текущем решении. Группировка по query_hash это сто шагов вперёд. В проект пока не включено. Надо новый проект сделать для такого способа.
И собираю данные в одну таблицу. Чтобы потом сделать по ней один отчёт в Excel, с раскраской. Как раз вчера сел за доработку проекта, чтобы отчёт Excel формировался сразу из программы.
Про триггеры не подумал. Опробую анализ триггеров в ближайшее время. Спасибо большое. Буду рад, если мои наработки по отчёту или группировке запросов также пригодятся вам в работе.
Главное отслеживать не все подряд, а подойти с вероятностной точки зрения (чего увы математикам и программистам приходит в голову не сразу-у меня тоже не сразу) и много «магии» так называемой эвристики-нужно упреждать появление проблемы при минимуме наблюдений и нагрузки на систему, а не все подряд анализировать.
На счет триггеров могу сказать, что 100% работа триггеров отразится на выполнение запросов и хранимых процедур. Поэтому может и нет смысла их анализировать все время. Будет что-то хуже выполняться, проанализируете. И если поймете, что в триггере могут быть проблемы, то либо включите наблюдение за триггерами конкретными, либо и без наблюдения разрешите проблему.
Спасибо за отзыв.
В нагрузочном тестировании бывает сразу не отследишь всё подряд, проведёшь тест, садишься писать отчёт, а уже поезд ушел, нет детального лога и взять его не от куда. Контролировать всё и сразу в бывает оправдано.
Запускаю трассировку по двум базам данных сразу — tempdb и целевой базе данных, tempdb активно используется внутри хранимок. Назвать реальных примеров, когда это было полезным не смогу, но когда-то решил так делать и делаю до сих пор.
И таблицу с результатами профайлинга создаю в отдельной БД, целевая база данных остаётся неприкосновенной. В текущей статье таблица TraceTable создаётся в целевой базе данных. Она обычно на отдельном диске, а tempdb на отдельном, создаю traceDB на том же диске, что и tempdb, чтобы разделить нагрузку на железо. Чтобы в резервную копию не попадали лишние данные. И чтобы не рос лог транзакций целевой базы данных.
Заменил бы строки ИМЯ_БАЗЫ_ДАННЫХ.dbo.TraceTable на строки traceDB.dbo.TraceTable, где traceDB — отдельная база данных, только для трассировки, без лога транзакций, без резервных копий.
И таблицу профайлинга TraceTable создаю каждый раз новую, за счёт использования даты и времени в имени таблицы TraceTable_20161107_0150. Храню для истории, удаляю руками.
В каждодневном администрировании контролировать всё, профилировать tempdb и хранить таблицы с трейсами, согласен, не нужно. Но создавать таблицу профайлинга, считаю, лучше в другой базе данных.
Для решения проблем с медленными запросами пока хватало Монитора актвности со списком Дорогих запросов
ну и далее план запроса, индексы циклы и т.п.
У нас правда пока 2016 не используется, да и Enterprise не везде поставить можно из-за финансовой составляющей, но предложенный Вами метод в будущем хорошо бы сравнить, чтобы понимать откуда берутся такие цифры
не влияя при этом на производительность.
Как мне кажется, необходимо добавить «практически» не влияя на производительность, как минимум диск то Query Store использует :)
Кроме того Query Store появился с позднего 2014-2016, так же имеет
Max Size (MB): Specifies the limit for the data space that Query Store will take inside your database..
Вообщем решение автора может пригодиться.
Реализация индикатора производительности запросов, хранимых процедур и триггеров в MS SQL Server. Автотрассировка