迁移后 SQL Server 性能不稳定

Question

我最近将一个 Web 应用程序迁移到了不同​​的数据中心。这包括将数据库从 SQL 2000 移动到 2005，这应该不是问题本身（我使用 SQL 2000 到 2008 R2 运行同一应用程序的其他实例）。

问题是，在迁移之后，一些操作，尤其是UPDATEs，变得非常慢（在我在应用程序中定义的任何限制之后超时，我尝试了长达 6 分钟）。

我尝试在 Management Studio 上运行相同的查询，但结果不一致。有时它只是立即运行，但有时它需要很长时间，我必须取消查询。在我的应用上，它总是超时（经典 ASP 应用）。

不止一个查询会发生这种情况，但最常见的查询如下所示：

UPDATE mytable SET timestampcol = GETDATE() WHERE record_id = 12345 /* record_id is the PK */

我已经尝试过的：

• 首先，我怀疑表大小（~2M 行）。所以我删除了旧记录，只留下了大约 40,000 行，但问题仍然存在。
• 然后我尝试重新创建索引，但没有成功。
• 我还尝试同时运行 sp_updatestats 和 sp_updatestats 'resample'，但没有成功。

所以，我被困住了。有谁知道可能发生的事情，我该如何解决？

更新

查看sys.dm_tran_locks，我可以看到在我的应用程序运行查询时有两个锁：

request_mode        request_type    request_session_id
S                   LOCK            65
IX                  LOCK            67

我还意识到S 锁出现在我尝试在 SP 调用上运行卡住的查询之前。我现在正在修改 SP 以尝试了解为什么在 SP 完成运行后锁定仍然存在。

更新 2 - Aaron Bertrand 问题的答案（参见 cmets）

• 过程是否使用事务？ 不，整个应用中没有交易

• 是否有任何代码路径可能无法提交事务？ N/A

• 谁在调用另一个存储过程？在有问题的查询前几行调用的是同一个脚本

• 您是否在 .NET 中使用某种事务上下文？不，它不是 .NET，它是经典的 asp（我必须维护旧的遗留代码）

• 为什么应用程序不调用存储过程？您的意思是直接从 (ADO) connection.execute 运行有问题的查询而不是？嗯，也试过了，结果一样。

• 为什么在 SSMS 中运行有问题的查询时调用其他存储过程不会影响您？我不知道！但是，无论我之前是否调用过 sp，更新目前都可以从 SSMS 运行。

伙计们，感谢你们的帮助，但我即将放弃这个。 在有人决定移动服务器之前，事情刚刚奏效。问题刚刚落在我手上，我会尝试将其传递给其他人。

Answer 1

sp_updatestats 如果没有创建合适的统计信息（表和索引），则什么也不提供。查看实际执行计划并查找缺失的统计信息（明确的警告和实际行与估计行之间的不匹配表明统计信息可能是错误的）

Answer 2

这原来是桌子上的一把锁。我仍然不明白为什么它会被锁定，但我通过在我的存储过程中添加 WITH(NOLOCK) 提示来解决它。