問題

對某個庫新增了一個訂閱節點，然后需要把一些應用切到新訂閱庫，以分散負載。當應用切換后，有一個應用每次啟動不到30秒，總是報超時的錯誤，而error log中又沒有任何記錄：

Timeout expired. The timeout period elapsed PRior to completion of the Operation or the server is not responding.The statement has been terminated.

但是切回連接到原來的訂閱庫就不會超時。

分析

1. 自先排查連接超時，找運維看連接配置，連接超時設定為90秒。排除之。

2. 排查語句超時，找到開發，說找不到歷史版本的源碼了，也就沒有辦法查看SqlCommand.CommandTimeout的設定值，無法繼續排查。

3. 1，2無果的情況下，用XE捕獲一下error信息，這個默認的system_health session就有：

Network error code 0x2746 occurred while establishing a connection; the connection has been closed. This may have been caused by client or server login timeout expiration.

Time spent during login: total 2407 ms, enqueued 0 ms, network writes 0 ms, network reads 2407 ms, establishing SSL 0 ms, negotiating SSPI 0 ms, validating login 0 ms,

including user-defined login processing 0 ms.

error code 0x2746 就是10054，使用NET HELPMSG 查看，結果為：Connection forcibly closed by remote host.

好了，到此為止，我斷定問題出在應用端。于是找上開發，運維一起討論，看他們能否詳細排查應用端，結論是：沒辦法。

4. 難道真的沒有辦法了？

既然超時信息能返回到應用端，那么我可以抓包，看到底出什么事了。于是使用Network Monitor一抓：

從抓到的信息來看，圖中選中的行，正是timeout的。它前一條記錄TDS：SQLBatch 從應用端發到服務端，過了一會兒，應用端就超時了。

這就很明顯了，應用端發了一個Batch給數據庫執行，等了一下它自己就說：我超時了。問題就出在這里，它發的是什么語句，執行了多久，造成了超時。

5. 用Profiler跟蹤：

此Batch執行大約用時20s,也得到了具體的語句。

6. 但是為什么切換到原來的訂閱庫就不超時，連接新的訂閱庫就會超時呢？

將5.中抓到的語句分別在兩個實例上執行，發現新的訂閱庫返回8W+行的數據，而舊的只返回6行數據且神速。

再進一步分析語句，原來舊的訂閱庫中，有一個非訂閱表，表中有大量用于篩選的數據;但新訂閱庫只有這個表，沒有數據。

于是將此表數據導入到新訂閱庫中的對應表中，兩者查詢的一結果一致了，應用也不超時了。據此推斷應用代碼中SqlCommand.CommandTimeout絕對小于20s.

總結：

1. 10054錯誤一個很出名的錯誤，原因有多種，比較難排查的一個問題。

2. 如果能這在2. 一步就能確認SqlCommand.CommandTimeout的設定值，并做相應調試排查，將會省了很多事。源碼管理的重要性啊！

3. 做事得細心，新增訂閱后，我只對比兩者的對象是否一樣，如果也核對了表中行數是否一樣，也就不會發生這事了。