Назад | Перейти на главную страницу

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

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

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

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

Меня в первую очередь беспокоит то, что это ухудшит производительность.

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

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


Full disclosure: I've posted the same question на сайте бета-версии администраторов баз данных. Serverfault members who want to support the DBA stackexchange site have the opportunity to answer the question there rather than here.

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

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

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

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

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