使用profiler工具的deadlock graph事件，可以非常友善直覺的捕獲死鎖資訊。方法是：
開啟mssql profiler：開始 -> 運作 -> 鍵入profiler
建立deadlock graph trace：在profiler窗體中，開啟一個trace -> 顯示所有事件 -> 依次找到locks -> deadlocak graph -> 運作（詳情參見下面的截圖，按照字母标号依次點選）。
注意這裡我們僅trace這一個事件就好了，取消其他多餘與死鎖無關的事件。
當死鎖狀況發生時，profiler捕獲到死鎖資訊，繪制成deadlock graph圖，非常直覺的展示了死鎖的程序、犧牲的程序和争搶的資源。
接下來就是分析死鎖發生時的情況，參加如下截圖：
通過死鎖關系圖的展示，我們可以分析如下：
犧牲程序：圖中最左邊被×掉的64号程序是死鎖犧牲品，它申請到了test_deadlock2的x鎖，再申請test_deadlock1的x鎖時，被做為了犧牲品。
死鎖程序：圖中最右邊63号程序首先擷取到了test_deadlock1的x鎖，然後申請test_deadlock2的x鎖，但這個時候64号程序已經拿走了test_deadlock2的x鎖。系統選擇殺死64号程序（即64做為了犧牲品），讓63号程序成功擷取到test_deadlock2的x鎖，他是本次資源争搶的獲勝者。
争搶的資源：圖中中部是兩個程序争搶的資源，我們可以通過圖中資源的hobt id擷取表和索引名，方法如下：
雖然通過deadlock graph圖可以很清楚的分析出死鎖的關系，找到資源的争搶點，但是我個人推薦分析deadlock trace檔案的方式，這種方式更加簡單明了。我們需要首先儲存deadlock graph監控資訊到檔案，比如儲存到c:tempdeadlock_testing.trc，方法如下：
檔案儲存完畢以後的.trc為字尾的檔案其實就是xml類型的檔案，我們可以使用接下來的語句進行分析xml檔案：
執行的結果如下截圖：
從這個分析結果來看，我們可以非常清晰明了得到如下資訊：
死鎖與被死鎖程序：63和64号程序
死鎖發生時，兩個程序執行的語句
死鎖的類型：本例是x鎖
鎖定資源的對象和索引名
死鎖的兩個程序執行的語句塊是什麼
程序執行所在的主機
......
我們既可以将deadlock graph儲存為trace檔案，還可以将其儲存到trace表中，假如我們将這個捕獲到的死鎖資訊儲存到本地資料庫表test.dbo.deadlock_testing中，方法如下：
分析deadlock trace table方法與分析deadlock trace file類似，隻需要将分析語句中的data公用表示稍微修改即可：
如果你是阿裡雲rds sql server 2008r2使用者，請工單聯系阿裡雲，申請執行個體的profiler權限，然後即可按照本方法來自行排查；如果你是阿裡雲rds sql server 2012使用者，預設已經具備profiler權限，無需申請權限。
使用profiler捕獲死鎖資訊的方法比使用dbcc的方式更加靈活，直覺，一目了然。希望阿裡雲rds sql server客戶借助本系列文章都可以自己動起手來，分析死鎖，解決死鎖的問題。