Окружающая среда:
Sql server 2008 r2
Windows 7 64 бит
Windbg 64bit
Что я уже знаю
Я могу найти sql stmts в этих транзакциях, запустив трассировку на стороне сервера и остановив ее, как только возникнет тупик. А затем поиск идентификатора транзакции в файлах трассировки. Но это метод грубой силы, который не всегда может быть реализован в производственной среде.
Я знаю, что должен отправить дамп памяти в Microsoft и затем проанализировать его. Но я хочу найти наш, если есть надежда решить это без частных символов.
Проблема:
Я создаю дамп памяти, используя расширенные события на сервере sql, когда 2 транзакции тупиковые (событие lock_deadlock).
Я вручную создаю этот сценарий тупика через студию управления.
Допустим, 1 из зашедшего в тупик xaction содержит 2 оператора sql.
begin tran
update tabl1 ... -- sql stmt 1
go
update tabl2 .. -- sql stmt 2
Теперь я нахожу эту ветку в своем дампе памяти и могу найти только мой sql stmt 2, т. Е. "Update tabl2".
В любом случае я могу посмотреть все sql stmts, которые поток выполнил в xaction, т.е. в нашем случае "update tabl1 .."?
Я хочу знать, что поток выполнял ранее в той же транзакции. Поскольку это действие еще не зафиксировано во время создания дампа, значения должны находиться где-то в памяти потока.
Пожалуйста, дайте мне знать, если я не имею здесь смысла. Я был после этой проблемы некоторое время и
я хочу знать, возможно ли это или нет.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Справочная информация:
У нас есть тестирование производительности env, где мы запускаем 12-часовые нагрузочные тесты. На следующее утро мы анализируем и обнаруживаем тупик. Приложение выполняет 7-8 операторов dml в транзакции (мы используем hibernate). Так как основанный на sys.dm_exec_sql_text будет давать результат только в том случае, если он находится в кеше, мы не получаем весь набор операторов dml, так как анализируем его на следующий день (ps: я даже не пробовал, когда о проблеме сообщили мне после 1 день)
Как мы решили эту проблему сегодня:
1. Настройте трассировку на стороне сервера
2. Настройте уведомление о событии, которое срабатывает при взаимоблокировке и вызывает sp, который останавливает трассировку.
3. Из расширенного отчета xml или профилировщика событий мы находим идентификатор транзакции и ищем прошлые операторы, соответствующие этому.
Как я думал, что смогу решить эту проблему:
1. Запустите дамп памяти при расширенном событии «lock_deadlock» с включенным системным идентификатором.
2. Как-нибудь попробуйте найти историю в потоке, соответствующем системному идентификатору.
Почему дамп памяти:
Потому что эта настройка окажет наименьшее влияние, если мне придется делать это на производстве.