Сокращение издержек трассировки SQL с помощью фильтров - PullRequest
Новая
       14

Сокращение издержек трассировки SQL с помощью фильтров

6 голосов
/ 13 ноября 2008

У нас есть сервер SQL 2000, который имеет различные задания, которые выполняются в разное время дня или даже в разные дни месяца. Обычно мы используем профилировщик SQL только для выполнения трассировок в течение очень коротких периодов времени для устранения неполадок производительности, но в этом случае это действительно не даст мне хорошее общее представление о видах запросов, которые выполняются к базе данных над курс дня, недели или месяца.

Как можно минимизировать издержки производительности при длительной трассировке SQL? Я уже знаю:

  • Выполнить трассировку на стороне сервера (sp_ create_trace) вместо использования пользовательского интерфейса SQL Profiler.
  • Трассировка в файл, а не в таблицу базы данных (что добавило бы дополнительную нагрузку на сервер БД).

Мой вопрос действительно о фильтрах. Если я добавлю фильтр только для того, чтобы регистрировать запросы, которые выполняются более определенной продолжительности или выполняет чтение, он все равно должен проверить всю активность на сервере, чтобы решить, нужно ли регистрировать его, верно? Таким образом, даже с этим фильтром трассировка будет создавать неприемлемый уровень издержек для сервера, который уже находится на грани неприемлемой производительности?

Ответы [ 4 ]

2 голосов
/ 13 ноября 2008

На самом деле сервер не должен обрабатывать трассировку, так как это может вызвать проблемы: «Когда сервер обрабатывает трассировку, никакие события не удаляются - даже если это означает, что производительность сервера снижается для захвата всех событий. Принимая во внимание, что Profiler обрабатывает трассировка, она пропустит события, если сервер будет слишком занят ". (Из практики экзаменационной книги SQL 70-431.)

2 голосов
/ 30 декабря 2008

Я нашел статью, которая фактически измеряет влияние производительности сеанса SQL-профилировщика на трассировку на стороне сервера:

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

Это действительно был мой основной вопрос, как убедиться, что я не перегружаю свой рабочий сервер во время трассировки. Похоже, что если вы делаете это правильно, накладные расходы минимальны.

2 голосов
/ 13 ноября 2008

Добавление фильтров минимизирует накладные расходы на сбор событий, а также предотвращает запись на сервер записей транзакций, которые вам не нужны.

Что касается того, будет ли трассировка создавать неприемлемый уровень издержек, вам просто нужно протестировать ее и остановить, если есть дополнительные жалобы. Использование подсказок DB Tuning Advisor с этим файлом рабочей трассировки может повысить производительность для всех завтра.

0 голосов
/ 18 ноября 2010

На самом деле можно собирать более подробные измерения, чем вы можете собрать из Profiler - и делать это 24x7 во всем экземпляре - без каких-либо накладных расходов. Это избавляет от необходимости заранее выяснять, что вам нужно отфильтровать ... что может быть сложно.

Полное раскрытие: я работаю на одного из поставщиков, которые предоставляют такие инструменты ... но используете ли вы наши или кто-то еще ... это может помочь вам решить основную проблему здесь.

Больше информации о нашем инструменте здесь http://bit.ly/aZKerz

...