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

Взаимоблокировки SQL 2005: запуск трассировки и изучение журналов

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

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

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

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

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

    • График тупиков
    • Блокировка: тупик
    • Замок: цепочка тупиков
    • RPC: завершено
    • SP: StmtCompleted
    • SQL: BatchCompleted
    • SQL: BatchStarting
  2. Нужно ли запускать трассировку до того, как действительно возникнет тупик, или я смогу запустить трассировку, когда мы заметим существенное снижение производительности?

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

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

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

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

Для # 2, если вы пытаетесь что-то зафиксировать, ИМО, вы должны запустить диагностику, а затем выполнить то, что вызывает тупик (при условии, что вы сузили его до определенной причины или типа события с приложением, или просто приложение в целом)

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