我们有一个程序连接到我们的数据库并运行一些存储过程来获取一些数据。
数据库是SQL Server 2008,程序在本地运行。连接是通过TCP / IP,但启用了共享内存。并且连接字符串的超时设置为45秒。
当我们通过SQL Server Management Studio运行它们时,运行需要0-5秒。 当我们通过代码运行它时,它会随机超时。
为了进行一些测试,我们将超时从45秒增加到几分钟。并且为了丢弃任何阻塞问题,我们检查了存储过程仅“选择”数据(没有插入或更新语句)。我们为select语句尝试了几个表修饰符,例如:nolock
,readpast
,...
我还检查了sp_who2
和dbcc opentran()
,但没有阻止任何内容...... .Net的SPID为running command ...
。有关.Net正在等待数据库答案的更多详细信息,通过SQL Server Management Studio,我可以毫无问题地运行相同的语句(存储过程或选择)。
有关正在发生的事情的任何建议吗?
答案 0 :(得分:4)
连接字符串超时仅影响登录超时。您似乎达到命令超时,只能通过修改CommandTimeout
来更改。默认值为30秒,建议值为0(无限超时)。
至于为什么你的程序会随机执行慢速,我建议先阅读Slow in the Application, Fast in SSMS? Understanding Performance Mysteries
顺便说一句,您的查询可能未被阻止。它执行一个不同的计划,只需要很长时间才能执行。在sys.dm_exec_requests
中检查last_wait_type
可能会显示IO等待(PAGEIOLATCH,在sys.dm_os_workers加入之后追逐任何红鲱鱼CXPACKET ...)。但是,重复我最初关联的Erland Sommarskog的更全面和更优秀的文章是毫无意义的。
答案 1 :(得分:0)
有两种超时:连接和查询。
如果您的查询超时,则是查询问题;但既然你说你可以通过SQL Server管理工作室运行它,我怀疑它是查询。
如果您的连接超时,则很可能是网络问题。我看到你已经进行过实验(锁定,提示等等),但你假设这是导致问题的查询。尝试从网络角度思考。我听说过SQL服务器中的活动监视器可以帮助您在连接期间检测网络问题。
答案 2 :(得分:0)
如果超时来自.net端,则将此2个参数添加到连接字符串。
超时= 3600000;
最大泳池大小= 360000;