Ускоряем Ms SQL Server

Юлия Шабунио

Что может быть хуже сервера, который неизвестно из-за чего стал работать слишком медленно? Только сервер, который работает слишком медленно по хорошо известной и неустраняемой причине! Чтобы реже сталкиваться с такой ситуацией, рассмотрим методы борьбы с причинами замедления работы Microsoft SQL Server.

В первой части статьи (см. «Почему MS SQL медленно работает? Ищем причины» – №5, 2005 г.) мы рассмотрели способы локализации проблемы, кроме одного – как обнаруживать дедлоки? Для начала изучим оставшийся вопрос и после этого перейдем непосредственно к сегодняшней теме.

Поиск дедлоков

Дедлоки (Deadlocks) являются довольно специфичной проблемой. С одной стороны, они не затрагивают весь сервер, а происходят на некоторых конкретных процессах. С другой стороны, если жертвы (снятые процессы) дедлока очевидны просто по журналу ошибок, то вот с каким процессом и на каких объектах случилось пересечение – непонятно. К счастью, в SQL Profiles входит великолепная возможность отследить всю цепочку блокировок с помощью LocksLock:Deadlock Chain. Чтобы эффективно ею воспользоваться, можно построить следующий шаблон:

1. События:

n  LocksLock:Deadlock Chain

n  LocksLock:Deadlock

n  Security AuditAudit Login

n  Security AuditAudit Logout

n  SessionExistingConnection

Первые два события нам нужны, чтобы отследить собственно блокировки. Остальные понадобятся для идентификации проблемного процесса. Дело в том, что событие «Deadlock Chain» ничего не пишет об участвующих процессах, кроме SPID. Поэтому нам потребуется регистрировать еще и входы и выходы из системы. По SPID и времени дедлока мы сможем точно найти записи о его подключении и отключении, а значит – найдём описание процесса. Событие «ExistingConnection» даст нам список тех процессов, на вход которых в систему мы уже опоздали.