很多人都知道,我常忝不知恥大言不慚自詡"台灣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千萬看仔細,敲錯天打又雷霹,只能乖乖重開機


Comments

# by Steve

黑大....是netstat -R還是nbtstat -R?

# by Jeffrey

to Steve, 是nbtstat -R才對,奶油桂花手又打錯字了。

Post a comment