Флаг трассировки 1222 не работает?

У меня есть клиентский сайт с двумя одинаково настроенными SQLr-серверами 2008r2 «A» и «C». На обоих серверах включены флаги трассировки 1204 и 1222, которые DBCC tracestatusпоказывают следующее на обоих серверах:

TraceFlag   Status  Global  Session
1204        1       1      0
1222        1       1      0
3605        1       1      0

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

Для жизни я не вижу никакой причины для этого различия. Я оба тщательно гуглил и прочитал (и перечитал) документ MS по этим флагам трассировки, и я не могу найти никаких сообщений о поведении, подобных этому, и никаких намеков на то, что может вызвать его. Единственное, что приближается, - это случайное утверждение, что ни один из флагов трассировки не работал, но все они оказались случаями, когда у них были опечатки в разрешающих командах. Я знаю, что это не так, потому что я использовал DBCC TRACESTATUS, чтобы подтвердить это.

Таким образом, любая информация о том, что может вызвать только флаг трассировки 1222, не работает и / или как это исправить, будет принята с благодарностью.

Ну, вот интересная разработка. Всякий раз, когда я сам генерирую взаимоблокировку (используя этот код: /programming/7813321/how-to-deliberately-cause-a-deadlock ), я получаю оба отчета о трассировке в журналах ошибок. Это только «естественные» взаимоблокировки, возникающие каждые несколько дней из приложений, которые, кажется, вызывают только один из отчетов о взаимоблокировках. Не уверен, поможет ли это, есть ли основания полагать, что трассировка 1222 не будет сообщать обо всех тех же тупиковых условиях, что и 1204?

— RBarryYoung
источник

Конечно, возможно, но все их серверы уже настроены таким образом, я не хочу менять их все, если я смогу заставить только этот работать правильно. Что касается не использования обоих, также возможно, но сейчас 1204 - единственный способ, которым я знал, что тупик произошел на C, и 1222 не сообщил об этом.

— RBarryYoung

Я не вижу причины для включения флагов трассировки для взаимоблокировок на SQL 2008, как xml_deadlock_report это уже является частью system_health session. Проверьте этот пост для более подробной информации. Проверьте это, чтобы увидеть, видите ли вы тупики.

— Кин Шах

@Kin Один большой недостаток встроенного отчета взаимоблокировки в system_health заключается в том, что sql_text не включен, поэтому может быть трудно устранить неполадки, связанные с запросами / объектами.

— Аарон Бертран

@AaronBertrand Я пробовал на RTM 2008R2, и он дает текст SQL, а также имя объекта

&lt;inputbuf&gt; BEGIN TRAN UPDATE dbo.DeadLockTest2 SET col1 = 1 UPDATE dbo.DeadLockTest SET col1 = 1   &lt;/inputbuf&gt;

; mode="X" associatedObjectId="72057594039107584", Я что-то пропустил ? Я использовал

SELECT CAST(xet.target_data AS XML) AS XMLDATA FROM sys.dm_xe_session_targets xet JOIN sys.dm_xe_sessions xe ON (xe.address = xet.event_session_address) WHERE xe.name = 'system_health'

— Кин Шах

@kin Я видел отключение запроса с помощью system_health. Это боль.

У меня была похожая проблема, не уверен, что она рассортирует вашу.

Попробуй это:

EXEC master..sp_altermessage 1205, 'WITH_LOG', TRUE;
GO

Даже при том, что это регистрировалось в журнале событий через флаг трассировки, это также должно быть установлено для того, чтобы вызвать электронные письма. Вы можете увидеть таблицу здесь:

select * from master.sys.messages
where text like '%deadlock%'

Вы можете получить более подробную информацию здесь

— Марчелло Миорелли
источник