Анализ трейса SQL Профайлера

        SQL Profiler, наверное, самый часто используемый инструмент SQL Server после Management Studio. И многие разработчики пользуются им для поиска тяжёлых запросов или анализа того, что происходит в системе. Чаще всего мы смотрим на трейс прямо в профайлере, пытаясь найти интересующие нас данные. Иногда мы добавляем некоторые условия и группировки для того, чтобы выделить только то, что нам действительно важно. Но это не очень эффективно. По-настоящему эффективный анализ рабочей нагрузки лежит за пределами профайлера.

        Сейчас я объясню что я имею ввиду. Анализ рабочей нагрузки в режиме реального времени, когда мы смотрим на бегущие строки в профайлере и пытаемся вычленить интересующие нас данные, не очень эффективен. Эффективен пост-анализ рабочей нагрузки. Есть 2 способа сохранить трейс. В файл и в таблицу. В первом случае, файл вы сможете открыть при помощи профайлера, и точно также просматривать его, как и в режиме реального времени, что тоже не очень эффективно. А вот вариант с таблицей, совсем другое дело. Колонки таблицы – колонки трейса профайлера, и такая таблица полностью готова к запросам и анализу. И возможности по анализу трейса по таблице ограничены только вашей фантазией и знанием SQL.

Например вы можете получить список вызовов интересующего вас запроса:

SELECT *FROM Profiler.dbo.Load
WHERE TextData LIKE '%usp_GetSomeData%'
Или отсортировать запросы по времени их выполнения:
SELECT * FROM Profiler.dbo.Load
ORDER BY Duration DESC

Само по себе время выполнения может быть не так важно, потому что запрос может выполняться редко, а запрос с меньшим временем выполнения будет выполняться часто. И в сумме именно он будет грузить вашу систему. Для определения того, суммарное время каких запросов было больше, можно использовать следующий запрос:

SELECT SUBSTRING(TextData, 0, 40), SUM(Duration), COUNT(Duration)
FROM Profiler.dbo.Load
GROUP BY SUBSTRING(TextData, 0, 40)
ORDER BY SUM(Duration) DESC

В этом примере SUBSTRING(TextData, 0, 40, используется для того, чтобы выделить общую часть у запросов. По сути, запросы разнятся передаваемыми параметрами. 40 символов – идеальное число для моей системы. Первые 40 символов позволяют мне понять какая именно хранимка выполняется, и в эти 40 символов практически не попадают значения передаваемых параметров. На вашей системе это число может отличаться.

        Как видите, такой анализ рабочей нагрузки очень эффективен. Приведённые примеры, это только вершина айсберга. Используя такой подход, действительно можно найти или выделить именно ту информацию, которая вам нужна.

PS: Сохранение трейса в таблицу – операция более тяжёлая, чем сохранение в файл. Но, вы можете, сохранив трейс в файл, открыть его затем профайлером и сохранить данные в таблицу для последующего анализа.

blog comments powered by Disqus

Обо мне

MVP

Data Architect at Intapp, Inc.

PASS Regional Mentor, CEE

MCT, MCITP, MCPD, MCTS


Microsoft MVP

Month List