Использование SQL Profiler для базы данных, которая находится в производстве

Как разработчик, я часто использую SQL Profiler. Это хороший инструмент для отладки, как для отслеживания того, что делает мой код, так и для анализа проблем с производительностью.

Но я всегда использовал его в своей среде разработки и очень контролируемым образом.

• Запустите мое приложение и приведите его в определенное состояние
• Запустить трассировку на профилировщике
• Выполнить определенную последовательность действий для моего приложения
• Остановите трассировку и изучите результаты.

Можно ли практически использовать SQL Profiler в производственной среде?

Мое первое беспокойство - это ухудшит производительность.

Мое второе беспокойство заключается в том, что, поскольку он находится в производстве, вы сами не запускаете интересные действия. Вы должны оставить профилировщик включенным на долгое время, а затем проанализировать результаты. Будет ли набор результатов слишком громоздким? (Занимая слишком много места на диске и слишком сложный для запроса).

Кто-нибудь использует SQL Profiler в производстве?

Использование Sql Server Profiler (инструмент с графическим интерфейсом) для отслеживания рабочего сервера не очень хорошая идея. Но это зависит от нагрузки. Вместо этого используйте трассировку sql на стороне сервера (см. Процедуры sp_trace_XXX ). Также я нашел статьи:

Влияние на производительность: трассировка профилировщика и трассировка SQL на стороне сервера ,

Автоматизация трассировки на стороне сервера в SQL Server

Избегайте проблем с Profiler

возможно это будет интересно и полезно.

Книга онлайн говорит:

• Запускайте Profiler удаленно, а не прямо на сервере
• Избегайте включения событий, которые происходят часто (например, Lock: Acquired), если в этом нет крайней необходимости
• Включить только необходимые классы событий
• Укажите ограничивающие фильтры, чтобы уменьшить количество событий
• Избегайте избыточных данных (например, SQL: BatchStarting и SQL: BatchCompleted)
• Избегайте запуска больших следов с помощью Profiler; вместо этого рассмотрим трассировку SQL на стороне сервера
• Ограничение размера файла трассировки на стороне сервера и управление использованием пространства

Я использую SQL Profiler против производства все время. Если все сделано правильно (фильтрация, чтобы вы возвращали очень небольшое количество данных) на сервер, риск минимален. Отслеживание всего было бы бесполезным.

1. Да, акт мониторинга потребует некоторых ресурсов. Запуск его на перегруженном сервере может убить его.

2. Вы на самом деле будете следить за реальной нагрузкой: ваши действия могут затеряться в шуме этой нагрузки.

Иногда мы запускаем его на производстве. В основном с текстовым фильтром для конкретного кода или с фильтрами ЦП / длительности, чтобы перехватывать более длительные запросы. И мы не пытаемся захватить планы выполнения XML или что-то подобное

Ключ в том, чтобы знать, что вы ищете: мы не склонны оставлять его запущенным и заманивать в ловушку все.

В этом случае, если вы хотите увидеть результаты некоторых действий, можете ли вы сделать это в нерабочее время?

Профилировщик всегда будет влиять на производительность.

Если вы используете SQL Server 2008R2 +, вы можете использовать расширенные события. Это обеспечивает большую часть информации, которую вы видите в профилировщике, с долей снижения производительности.

Электронное введение в книги http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Эта функция получила большое обновление в SQL Server 2012, который теперь включает графический интерфейс в SSMS.