【茶包射手日記】MSDTC茶包經驗再添一筆

很多人都知道，我常忝不知恥大言不慚自詡"台灣MSDTC茶包權威"，甚至前幾天，為了同事在我的管區隱匿個人主機與跨網域SQL分散式交易問題超過一個月而大發雷霆!(謎之聲: 茶包大人好大的官威呀~~~) 所幸該茶包行蹤敗露後，經我設定lmhosts後十秒就被送上西天，這更讓我志得意滿好不驕傲。心想，這世上應該沒有任何MSDTC茶包可以難得倒我了，哇哈哈哈! (謎之聲: 瞧這小人得志嘴臉，不可取!)

果不其然，自大是要遭天譴的!

今天受命處理一台同樣疑似跨網域MSDTC問題的測試機。使用Mini C#法很快地確認為MSDTC問題無誤(第二條連線出現Communication with the underlying transaction manager has failed.)，熟練地在Client與SQL Server的lmhosts加上對方的IP及機器名稱，nbtstat -R後，心想自己已達"談笑間茶包灰飛煙滅"的境界，嘴角不禁上揚。沒想到，此時Mini C#傳來無情的打擊: 登楞! ommunication with the underlying transaction manager has failed.依然存在。

從SQL主機Component Services主控台中的Distrubuted Transaction Coordnator/Transaction Statistics，可以觀察到每試一次，Aggregate/Aborted的數字就加一，我猜測是SQL端無法以機器名稱解析Client端的緣故。但做了ping clientMachineName的測試，明明有回應，傳說中的茶包大王黔驢技窮方寸大亂...

胡亂摸索了十來分鐘，開始讖悔自己不夠謙卑，忘了對茶包要永遠保持敬畏。終於，老天爺原諒了我，解除鬼遮眼，這才發現在SQL主機的lmhosts中，我誤把Client IP由192.168.8.177打成本地網段192.168.1.177，而碰巧它是個存在IP，在ping clientMachineName時，沒留意到回應的IP是1.177而不是8.177... 一整個豬頭白目奶油手，怪不得別人。

知錯能改，把lmhosts校正好，重啟兩邊的MSDTC，無效! 重啟SQL Server，還是無效! 試著反覆nbtstat -R甚至ipconfig -flushdns都抺不去錯打IP造成的影響，只好摸摸鼻子，通知相關人員暫停作業，執行3R(Restart, Reboot, Reinstall)中的第二重--Reboot。終於在重新開機後，分散式交易順利運作。

抽得老天御賜籤詩一枚: 跨網設定DTC，IP千萬看仔細，敲錯天打又雷霹，只能乖乖重開機