The explanation of the defect in the article is over simplified, and was written based on my first findings when looking at the bug. He had read my article on SQL Server Central and noted that there was a discrepancy in the explanation of the bug in the XML when compared to the actual work around that corrects the bug. I eventually gave up trying a few days later, due mostly to the fact that I was going to be gone for two months, but it was something in my list of things to figure out.įast forward to last week when I got an email from Yuxi Bai, a member of the SQL Development team who actually worked on the Deadlock Monitor. I was warned that they can be difficult to actually produce, but it is possible to do. This sparked my interests and I tried for a few days tirelessly to actually create a multi-victim deadlock to no avail. During this exchange it was brought up that the Deadlock Monitor in SQL Server was reworked to add support for Multi-Victim Deadlocks, and the new XML output in Extended Events can be used to identify such a monster. When I first encountered the bug, I traded emails with Jerome Halmans, one of the developers for Extended Events, who confirmed the bug, and helped me validate the workaround to generate valid XML. That bug was filed with Microsoft and is covered in the following connect feedback: In writing that article I happened upon a bug that is covered in the article with a work around in the Deadlock XML that is output by the Extended Events Engine. At the beginning of the year, I wrote an article titled Retrieving Deadlock Graphs with SQL Server 2008 Extended Events that detailed how to use the default system_health session to retrieve deadlock graphs from SQL Server 2008 without having to use SQL Profiler, SQL Trace or enabling a Trace flag on the SQL Server.
0 Comments
Leave a Reply. |