史丹利好熱

星期六晚上沒有想看的球賽，來筆記幾個月前碰到的問題: Intra-Query Parallel Thread Deadlocks，內部平行查詢死結。

在繁忙的線上交易資料庫(OLTP)世界裡，當兩個以上Session都在等待存取彼此鎖定的資源時，資料庫就會出現死結而有交易需要被犧牲。就像最近聯合航空強拉旅客下機的事件裡，發生超額訂位且check in後，似乎有航空公司處理的標準；在SQL DataBase Engine中，也有一套選擇下機旅客的標準，只記得會選擇交易復原成本(Cost)較低的犧牲(買促銷票的)，有沒有其他要注意的點?

除了Trace flag及SQL Profiler能野生捕獲DeadLock資訊，在SQL Server 2008開始，也多了一個擴充事件(Extended events)的工具可以幫助我們，到了SQL Server 2016，雖然Trace flag及SQL Profiler都還能運作，但考慮到SQL Profiler對於Server負載的衝擊以及將來SQL產品的支援，我們就是慢慢把系統診斷的工作轉移到擴充事件中嚕~

Profiler是SQL Server 2005開始提供的工具，一直以來都是我們診斷案件錄製SQL內部過程的好幫手，她可以讓我們建立和管理追蹤交易過程，蒐集到資訊後也能直接進行分析並且重新執行追蹤結果，我們來試試看捕捉DeadLock事件。

Trace flag是老牌但超實用的系統診斷及暫時關閉特定伺服器功能的工具，從SQL Server 2000的前一代SQL 7.0就出道了，

如果想把Deadlock的資訊儲存在SQL Server紀錄檔中，我們可以啟用Trace flag 1222以及1204。

最近的案子中，在測試及正式環境都碰到了幾次資料庫交易死結(DeadLock)而有交易被犧牲，有一次還碰上了查詢交易的死結(內部平行查詢死結intra-Query Parallel Deadlock)，由於SQL Server發生死結(DeadLock)的原因很多，因為經驗不足，自己沒碰過的碰過的多，踏出解問題的第一步就是紀錄死結資訊。

來筆記幾種觀察死結問題的工具。

• Trace flag(1222,1204)
• SQL Profiler
• Extended events