我们有一个连接到我们的数据库并运行一些存储过程以获取一些数据的程序。
数据库是SQL Server 2008,该程序在本地运行。该连接通过TCP/IP,但是启用了共享内存。连接字符串的超时设置为45秒
当我们通过SQL Server Management Studio运行它们时,运行需要0-5秒。当我们通过代码运行它时,它会随机耗尽。
要进行一些测试,我们将超时从45秒增加到几分钟。还要丢弃任何阻止问题,我们检查了存储过程仅"选择"数据(没有插入或更新语句)。我们已经尝试了几个选择语句的表修饰符,例如: nolock
, readpast
,...
我还检查了sp_who2
和dbcc opentran()
,什么也没有阻止... .NET的蜘蛛是running command ...
。有关更多详细信息,而.NET正在等待数据库答案,请通过SQL Server Management Studio我可以运行相同的语句(存储过程或选择)而不会出现问题。
关于发生的事情的任何建议?
连接字符串超时仅影响登录超时。您似乎会击中命令超时,并且只能通过修改CommandTimeout
才能更改。默认值为30秒,推荐值为0(无限超时)。
至于为什么您的过程命中随机缓慢执行,我建议您首先阅读应用程序中的慢速执行,SSMS中的快速执行?了解性能之谜
顺便说一句,您的查询可能不会阻止。它执行了一个不同的计划,该计划只需要这么长时间才能执行。在sys.dm_exec_requests
中检查last_wait_type
可能会揭示IO等待(Pageiolatch,在Chasse Chasse沿SYS.DM_OS_OS_WORKERS加入的任何红色herring CXPacket加入...)。但是,我最初链接的Erland Sommarskog毫无意义地重复了更全面和出色的文章。
有两种超时:连接和查询。
如果您的查询时间是一个查询问题;但是由于您说您可以通过SQL Server Management Studio运行它,所以我怀疑这是查询。
如果您的连接时间耗尽,则很可能是网络问题。我看到您已经进行了试验(锁,提示等),但是您假设是引起问题的查询。尝试用网络思考。我听说过SQL Server中的活动显示器,这可能会帮助您在连接期间检测网络问题。
如果超时来自.net侧,则将此2个参数添加到连接字符串。
超时= 3600000;
最大池尺寸= 360000;