问题
对某个库新增了一个订阅节点，然后需要把一些应用切到新订阅库，以分散负载。当应用切换后，有一个应用每次启动不到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. 做事得细心，新增订阅后，我只对比两者的对象是否一样，如果也核对了表中行数是否一样，也就不会发生这事了。
一次SQL Server 10054 Troubleshooting,布布扣,bubuko.com