2. Поля данных:

n  EventClass

n  SPID

n  StartTime

n  ObjectID (объект, на котором был дедлок)

n  IndexID (индекс, участвовавший в дедлоке)

n  Mode

n  EventSubClass (в каком режиме была попытка блокировки)

n  стандартные поля для определения смысла процесса – Application Name, NTUserName и так далее

n  TextData

Первые два поля я выношу в список полей, определяющих порядок сортировки (называется он почему-то Groups).

3. Фильтры в данном случае никакие не нужны. Подключение/отключение пользователя не самое частое явление в работе сервера, а уж дедлоки и подавно.

Итак, шаблон готов. Сохраняем, запускаем и... готовимся к долгому ожиданию. Редко сервер доходит до такого состояния, что дедлок случается каждую минуту. Даже в очень тяжелых случаях приходится подождать пару часов, а то и дней, прежде чем наберётся материал для анализа. Поэтому я советую настроить сохранение счётчиков в файл и забыть о них на сутки как минимум. Особенностью в данном случае является еще и то, что когда у вас упорядочение задаётся по нескольким полям в Groups, то работать с ними в онлайн-режиме очень неудобно: из-за ошибки в профайлере курсор всё время скачет. Приходится или останавливать процесс сбора информации, или работать с сохранённым файлом журнала.

При анализе обратите внимание на то, что событие Deadlock Chain реализуется одним и тем же процессом с маленьким номером. Это системный процесс, который следит за ошибками, но сам в них не участвует. Процессы-участники дедлока указываются в TextData события Deadlock Chain.