”這SQL作業一直每天都運行好好的，咋突然就不生效了？”
碰到這種突發問題，我心里是淡定的，事情不可能莫名發生的，因為是SQL作業問題，首先需要查看作業歷史記錄
果然一個大大的X明顯的不要不要的，繼續看錯誤內容：
已以用戶 NT AUTHORITY\NETWORK SERVICE 的身份執行。 事務(進程 ID 51)與另一個進程被死鎖在 鎖 | 通信緩沖區 資源上，並且已被選作死鎖犧牲品。請重新運行該事務。 [SQLSTATE 40001] (錯誤 1205). 該步驟失敗。
死鎖？，好好的事務咋會死鎖了，查看前一天所有員工工作記錄，發現沒有任何人對這個作業里面的存儲過程做過更改，保險起見，還是人工喊了句：“昨天有沒人改XXX啊？” “木有哦” “改它有錢拿嘛” “XXX是啥？” 好吧，你們贏了，既然這個PRO（存儲過程）沒人動，那就是其他的事務掛了干擾了這里面的操作，從而導致死鎖了，木辦法，死辦法了，看存儲過程，一打開，不愧是別人寫的代碼，上千行啊，作為一個好久沒看過代碼的非主流程序員，壓力無限大啊，壓制住想吐的心理，查找所有對表發生更改的操作，篩選出可能受影響的表，再找員工工作記錄（吐槽下員工工作記錄非常重要），果然昨天有人對其中的表做了更改，於是找到對應的人，好吧，事情差不多明了，問題就出在這二貨的代碼上，對方表現的很無辜，“我測試過啊，代碼運行正常，為什么自動執行就出錯了，巴拉巴拉...”不吐槽程序員的失誤了，繼續定位問題：
問題發生情況：
在SQL存儲過程中對其他服務器的SQL數據庫進行操作，外加個前提：使用了事務
錯誤信息：
無法執行該操作，因為鏈接服務器 "xxxxx" 的 OLE DB 訪問接口 "SQLNCLI" 無法啟動分布式事務
找了下資料，http://www.cnblogs.com/qanholas/archive/2013/05/15/3080013.html 大神們都是這種標答，標答不愧為標答，寫的太詳細了，考慮了各種情況，但是吐槽啊，內容太多，找到有用的信息好難，我這里對內容進行下篩選，問題基本就是服務器配置問題，解決方案如下，來個有圖有真相吧：
步驟一：進入服務器(那個出錯的鏈接服務器)，找到控制面板--管理工具--組件服務（知道命令行打開組件服務的就直接打開吧）
步驟二：組件服務--計算機---我的電腦---右鍵---屬性
步驟三：屬性窗口：選擇MSDTC--安全配置
步驟四：勾上下圖那些圈圈，然后確認了（到這一步如果你發現沒勾，那么恭喜你，勾上問題就解決了，如果發現已經勾上了，那么sorry，你只能按照上面大神的鏈接，一個個去排查了，GOOD LUCK！）
確認后，去執行出錯的那個PRO，果然，錯誤沒了，再測試下，沒問題，注銷服務器，收工，問題解決！
[ps：后續又因為服務器配置變更導致問題：無法啟動鏈接服務器 "MOSSDB" 的 OLE DB 訪問接口 "SQLNCLI10" 的嵌套事務。由於 XACT_ABORT 選項已設置為 OFF，因此必須使用嵌套事務，需要重啟服務，原因是嵌套的存儲過程在事務執行的過程中有人進行了變更，導致死鎖]
綜上，事務調用事務風險還是大了