在 SQL Server 2008 R2 上执行存储过程的瞬时问题

Question

我们遇到了 SQL Server 2008 R2 64 响应存储过程调用的问题。大约每两周左右，数据库停止响应从 ADO 连接/命令集（4.0 框架）调用的存储过程。我们已经为此工作了几个月，几乎没有改进。

系统变化：

我们通过他们的升级方法将现有供应商产品从 SQL Server 2005 升级到 SQL Server 2008 R2。数据库实例从 32 位 Windows 2003 Server 移动到 64 位 Windows 2008 Server。

失败的模式：

该应用程序全天运行，由不同用户通过 Citrix 执行，没有问题。每隔几周，应用程序就会在相同的时间范围内停止响应。一旦数据库停止响应应用程序的托管实例，应用程序的任何过程执行都会挂起（安装在 CITRIX 服务器上，安装在不同的物理系统上，或在 VStudio 2010 中调试）。在检查日志、服务器状态、SQL 监控工具、跟踪重复执行尝试一小时后，服务器决定在不干预的情况下响应应用程序。

奇怪的是，当服务器没有响应 ADO.Net 调用时，我们从 SQL Server Management Studio 执行存储过程并在 1 到 2 秒内收到结果。我们使用相同的登录名访问 SQL Server Management Studio，并使用相同的参数执行存储过程。

查看传递给 ADO 连接的连接字符串，我没有发现任何异常：

connectionString="Data Source=myserver\myinstance;Initial Catalog=databaseName;Persist Security Info=True;User ID=xxxxx;Password=yyyyy;Connect Timeout=45" 

到目前为止尝试过：

• 为操作系统增加了 2GB 的 RAM：没有变化
• 添加了额外的 tempdb 文件，将 tempdb 日志文件的大小从 1gb 扩大到 5gb：将问题从每周减少到每 2 或 3 周。
• 已安装 SQL Server 2008 R2 SP3：没有变化。

乌云：

对我来说，重复时间模式的故障意味着数据库主机（服务器或资源）存在问题，但 DBA 看不到负载或资源问题。如果它纯粹是主机问题，为什么它响应 SQL Server Management 调用而不是 ADO.NET 调用？

最后一次出现持续了两个多小时，并在重新启动数据库服务器后得到解决。不是一个很好的后备，但绝望的时候和所有...... ..

Answer 1

更新 ADO.NET 连接以使用命名管道已经解决了我们的应用程序的问题。以“np:”为前缀的数据库名称具有使用命名管道的连接。

connectionString="Data Source=np:myserver\myinstance;Initial Catalog=databaseName;Persist Security Info=True;User ID=xxxxx;Password=yyyyy;Connect Timeout=45" 

问题于 5 月 14 日返回。这个query timeout posting 提示了我们如何强制 SQL Management Studio 表现得像 ADO.NET 连接，并让我们认识到这是一个“参数嗅探”问题。我们已应用更改来禁用存储过程中的参数嗅探。