SQL 2005 Deadlocks: отслеживание и проверка журналов

У нас есть стороннее коммерческое приложение, которое, по нашему мнению, приводит к возникновению взаимоблокировок на нашей машине с SQL Server 2005 (64-битной). Уходя от полуторадневного обучения с поставщиком программного обеспечения на прошлой неделе, чтобы помочь нам лучше администрировать программное обеспечение, я сейчас провожу некоторые исследования о том, как наилучшим образом использовать SQL Server Profiler и Trace Templates в меру моего преимущества.

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

Чем больше я узнаю этих ребят (поставщик программного обеспечения), тем меньше я ими впечатлен - и тем больше "закулисной" работы я хочу сделать сам. Например, у нас в течение нескольких месяцев были проблемы с замедлением работы сервера до сканирования, но на данный момент я не вижу абсолютно никакого файла трассировки или файла шаблона трассировки в системе.

На мои вопросы...

  1. Заметно ли выполнение файла трассировки влияет на производительность сервера? Я думаю, что ответ будет "это зависит". Если это так, то вот "события", которые я выбрал для нового шаблона трассировки, который я только что создал:

    • График тупика
    • Блокировка: тупик
    • Lock: тупиковая цепь
    • RPC: Completed
    • SP: StmtCompleted
    • SQL: BatchCompleted
    • SQL: BatchStarting

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

  3. Сейчас я читаю советы и приемы просмотра журналов SQL, поскольку мы не уделяли этому много внимания. Когда я захожу в SQL Server Management Studio, захожу в раздел "Управление" и "Журналы SQL Server", я не могу найти там ничего, что говорит о "взаимоблокировке" / "взаимоблокировке" и т. Д. Так что, возможно, ничего не блокируется. Может ли кто-нибудь подтвердить для меня, появятся ли Deadlocks в журналах SQL, и если да, что я могу использовать в моих критериях поиска, чтобы найти записи?

Источник

2 ответа

Решение

Выполнение трассировки на SQL Server повлияет на SQL Server. Основное правило заключается в том, что все, что вы делаете на сервере, требует ресурсов. Могут ли вы вызвать проблемы с производительностью при запуске трассировки или SQL Profiler против SQL Server? Да, вы уверены, что можете, если у вас нет никакой фильтрации на месте.

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

Источник

Что касается ведения журналов диагностики, таких как Trace, он использует меньше ресурсов, чем Profiler, но, как всегда, ответ зависит от спецификаций вашего сервера, а также от того, сколько происходит сразу во время нормальной работы. Поскольку вы работаете только с SQL 2005, я предполагаю, что аппаратное обеспечение немного длинное, что означает, что вы должны быть осторожны при запуске его на производственном компьютере. Что на самом деле не рекомендуется в любом случае, если вы пытаетесь устранить проблему вслепую или даже на совершенно новой коробке.

Для #2, если вы пытаетесь захватить что-то, IMO, вы должны запустить диагностику, а затем выполнить то, что вызывает тупик (при условии, что вы сузили его до определенной причины или типа события в приложении, или просто приложение в общем)

К сожалению, не могу помочь с № 3.

Источник
Другие вопросы по тегам