上篇文章中, 我们总结了SharePoint里的timeout相关的设置, 文章中我们说到SQL端的选项是不会有什么影响的. 为什么这么说呢?
笔者这一块原来也是晕乎乎. 于是去咨询SQL的资深高级技术支持工程师Peter, 得到了如下的答案.
1. 与SQL相关的timeout, 都是由Client端发起的.
比如说, 我们自己写了个C#小程序, 其中使用了SqlCommand.CommandTimeout属性, 指定它的值为20秒. 那么, 当这个query在SQL端执行了二十秒后, 我们的C#小程序会给SQL Server发送一个TDS Tension数据包, 告诉SQL Server我这边超时了, 你那边的query不用做了. 于是SQL相应client的请求, 断掉connection. Client端报出一条exception, 说SQL Server端的运行时间太长, 超过了我们原定的时限.
2. 那么SQL Server Management Studio中有如下两个有关Timeout的选项, 他们是干什么的呢?
- a. Tools->Options->Query Exection->Execution time-out.
- b. Right click SQL Server Node->Properties->Connections->Remote Query Timeout.
如果我们把Management Studio看作是我们自己写的C#程序, 在这个程序中我们只写下来要执行的语句, timeout设置呢? 这里的a选项指定的值就是SqlCommand.CommandTimeout. 好懂吧. ^_^
假设我们的C#小程序连接到SQL Server 1上运行存储过程取数据, 在这个存储过程中, SQL Server 1需要到SQL Server 2上去取原始数据. 那么, 如果SQL Server 2上的查询执行了600秒之后(默认值), 那么SQL Server 1会发给SQL Server 2, 告诉它这个查询我嫌它太久, 你不要做了. 于是SQL Server 1 发给SQL Server 2一个数据包, 告诉它停吧. 然后Server 2断掉他们之间的Connection.
由此可见, 在一般情况下, b选项与我们关系不是很大.
我在研究这两个选项的时候, 发现StackOverFlow.com上的网友问起相关的问题, 回答问题的人经常给出这两个选项. 其实这是错误的. 调整了之后也不会对SQL端运行超时的问题有改善的.
感谢Peter Zhu提供的精彩讲解, 我在这里才能分享给大家.
技术无止境, 这么小的一个选项后面竟然有这么多猫腻呀.