Факт дидлока SQL возвращает. Но в TextData тела sql-кода нет. он есть только в предыдущей строчке трейса


Сижу думаю из какой именно предыдущей строки трейса (batchcompleted) вытащить тело кода который поймал дидлок

В самом deadlock-ивенте фигня какаято:
TextData: user_type_id = 257
BinaryData: 0x07010100000000000000000001000B

Единственная полезная инфа в deadlock-ивенте это Duration. Почему же так скудно. Как вытащить больше деталей?

Здравствуйте, VladCore, Вы писали:

VC>Единственная полезная инфа в deadlock-ивенте это Duration. Почему же так скудно. Как вытащить больше деталей?
На всякий случай спрошу. Deadlock Graph пробовал?

Здравствуйте, VladCore, Вы писали:

VC>Факт дидлока SQL возвращает. Но в TextData тела sql-кода нет. он есть только в предыдущей строчке трейса

VC>...
VC>Единственная полезная инфа в deadlock-ивенте это Duration. Почему же так скудно. Как вытащить больше деталей?

Выше правильно сказали, необходимо использовать событие Deadlock graph. Результат можно сохранить отдельно в виде xml файла, либо в самом Profiler навести мышкой на узел процесса и получить текст запроса. Более трудоемкий вариант, использовать событие Lock:Dealock Chain для определения процессов (SPID), на которых возникла взаимоблокировка, а сам текст запроса выбрать из событий ...Starting и ...Completed с соответствующим SPID.

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, VladCore, Вы писали:

VC>>Единственная полезная инфа в deadlock-ивенте это Duration. Почему же так скудно. Как вытащить больше деталей?
_AB>На всякий случай спрошу. Deadlock Graph пробовал?

Мне и в рантайме надо.

Здравствуйте, Olaf, Вы писали:

O>Выше правильно сказали, необходимо использовать событие Deadlock graph. Результат можно сохранить отдельно в виде xml файла, либо в самом Profiler навести мышкой на узел процесса и получить текст запроса. Более трудоемкий вариант, использовать событие Lock:Dealock Chain для определения процессов (SPID), на которых возникла взаимоблокировка, а сам текст запроса выбрать из событий ...Starting и ...Completed с соответствующим SPID.

Интересная мысль. Найти t-sql по SPID выглядит логично. Но вот только нигде не написано что 25-й ивент логируется после RPCCompleted иди Batch-completed.
Было бы логчнее если бы сначала логировалось deadlock, а потом уже соответсвующий completed.

Здравствуйте, VladCore, Вы писали:

VC>Мне и в рантайме надо.
И? В чем проблема?

Здравствуйте, VladCore, Вы писали:

VC>Единственная полезная инфа в deadlock-ивенте это Duration. Почему же так скудно. Как вытащить больше деталей?

А вот это что выдаёт?

SELECT XEvent.query('(event/data/value/deadlock)[1]') AS DeadlockGraph
FROM (
    SELECT XEvent.query('.') AS XEvent
    FROM (
        SELECT CAST(target_data AS XML) AS TargetData
        FROM sys.dm_xe_session_targets st
        INNER JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
        WHERE s.NAME = 'system_health'
            AND st.target_name = 'ring_buffer'
        ) AS Data
CROSS APPLY TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(XEvent)
) AS source;

?
(с) https://social.technet.microsoft.com/wiki/contents/articles/31280.finding-and-extracting-deadlock-information-using-extended-events.aspx

Здравствуйте, VladCore, Вы писали:

VC>Интересная мысль. Найти t-sql по SPID выглядит логично. Но вот только нигде не написано что 25-й ивент логируется после RPCCompleted иди Batch-completed.
VC>Было бы логчнее если бы сначала логировалось deadlock, а потом уже соответсвующий completed.

Так и есть, если ориентироваться на EventSequence, то события идут в следующем порядке Lock:Deadlock Chain, Deadlock graph, Lock:Deadlock, а потом completed

	Картинка

Здравствуйте, Olaf, Вы писали:

VC>>Интересная мысль. Найти t-sql по SPID выглядит логично. Но вот только нигде не написано что 25-й ивент логируется после RPCCompleted иди Batch-completed.
VC>>Было бы логчнее если бы сначала логировалось deadlock, а потом уже соответсвующий completed.

O>Так и есть, если ориентироваться на EventSequence, то события идут в следующем порядке Lock:Deadlock Chain, Deadlock graph, Lock:Deadlock, а потом completed

О том и речь! Сначала идет completed (12) а потом дидлок (25)



Кстати, а что значит 0x07010100000000000000000001000B в BinaryData?

Здравствуйте, VladCore, Вы писали:

VC>Здравствуйте, Olaf, Вы писали:

VC>>>Интересная мысль. Найти t-sql по SPID выглядит логично. Но вот только нигде не написано что 25-й ивент логируется после RPCCompleted иди Batch-completed.
VC>>>Было бы логчнее если бы сначала логировалось deadlock, а потом уже соответсвующий completed.

O>>Так и есть, если ориентироваться на EventSequence, то события идут в следующем порядке Lock:Deadlock Chain, Deadlock graph, Lock:Deadlock, а потом completed

VC>О том и речь! Сначала идет completed (12) а потом дидлок (25)

Я не увидел у вас сортировки по EventSequence при обращении к fn_trace_gettable, отсортируйте и все встанет на свои места.

VC>Кстати, а что значит 0x07010100000000000000000001000B в BinaryData?

Вроде как идентификатор ресурса блокировки Lock:Deadlock, но по факту что-то непонятное select cast(0x07010100000000000000000001000B as nvarchar(max)) Возможно для внутреннего использования самим Profiler'ом.