从 SQL Server 2005 迁移到 2012 后的性能问题

Question

上周五，我将 SQL Server 实例从 2005 Enterprise Edition 迁移到安装了 SQL Server 2012 Enterprise Edition 的全新 Windows Server 2012 服务器。从那时起，用户开始抱怨应用程序的性能。

以下是有关服务器的一些信息：

• VMWare 5.5 上的虚拟服务器
• 4 个 vCPU 和 24 Gb RAM。在之前的配置中，10 Gb 是必要的，但 tempdb 数据库比我设置的要小（几乎 6Gb）
• 我现在已将最大内存目标设置为 22 Gb，并且 tempdb 完全在缓冲池中
• 迁移后（使用数据库镜像执行），我运行了更新统计、索引重建和其他维护命令

我不知道在哪里可以找到答案。如果除 SQL Server 实例之外的所有内容都相同（VM、磁盘等），那么对我来说，问题出在 SQL Server 配置中，但在哪里呢？我尝试了一些更改，但似乎没有一个有用。

你有什么想法？

来自评论的附加信息

• 我运行了 sp_Blitz，它给了我一些信息，但 SQL 2005 没有什么新东西（例如存储速度慢）
• 内存消耗 (20Gb + ) 主要是由于 tempdb (6Gb)，其余大部分由应用程序数据库占用
• PLE 流，有时会下降到 150。在一天开始时，大部分数据都在缓存之外
• 之前服务器上的最大内存设置为 10Gb
• 我们使用 Idera 诊断管理器
• 最大服务器内存设置为它在前一个服务器上的值的两倍。
• 页面寿命至少每天两次低于 150

sp_BlitzIndex 分析

我开始使用 sp_BlitzIndex 进行分析，除了编写糟糕的代码外，它还显示了这一点：

• 主动索引：总锁等待时间 > 5 分钟（行 + 页）

  dbo.TABLE1.PK_TABLE1 (1): 
  Row lock waits: 3,591; total duration: 10 minutes; avg duration: 0 seconds; 
  Page lock waits: 23; total duration: 15 seconds; avg duration: 0 seconds; 
  Lock escalation attempts: 510,489; Actual Escalations: 1.
  
  dbo.TABLE1.I_TABLE1_CNTTYPE_CATEGORY_IS_CURRENT (85): 
  Row lock waits: 155; total duration: 48 seconds; avg duration: 0 seconds;
  Page lock waits: 129; total duration: 8 minutes; avg duration: 4 seconds;
  Lock escalation attempts: 29,423; Actual Escalations: 4,951.
  

仅仅创建一个额外的索引会对该现象做一些改变吗？

sp_configure

我已经按照要求比较了 sp_configure 的输出。以下是差异：

Config                          Old     New
Blocked process threshold       0       120
Maximum Degree of parallelism   0       4
Maximum Memory (MB)             10240   22000

电源选项已经处于高性能状态。我使用以下命令将内存设置回 10 Gb：

CHECKPOINT ;
DBCC DROPCLEANBUFFERS ;
EXEC sys.sp_configure N'max server memory (MB)', N'10240'
GO
RECONFIGURE WITH OVERRIDE
GO

使用 10Gb 内存运行一小时后：最后一个区别是 tempdb 的大小，它比旧服务器上的要大，并且现在使用了大部分内存，导致页面预期寿命几乎为 490。

分析诊断管理器 CPU 统计报告

CPU 统计报告：

• 平均 SQL 编译为 500
• 平均 SQL 重新编译为 120
• 每分钟最多 10 次锁定等待，平均 5 次
• 大多数情况下，表锁升级平均为 40。

我已经为临时工作负载服务器设置优化，甚至为最常用的用户数据库设置了“强制参数化”。

到目前为止，没有人告诉我有性能改进。因为它是我拿回来的一个数据库，不是由 DBA 团队管理的，所以我们没有背景来检查它是否恢复正常...

我会等一段时间，看看现在是否可以。谢谢大家的帮助 ！

Answer 1

最可能的解释是，由于统计信息、索引大小和密度以及配置设置的变化，您的查询正在新服务器上使用不同的执行计划执行。

对查询优化器执行计划选择影响最大的配置设置是：

• max server memory
• max degree of parallelism
• cost threshold for parallelism

问题指出新安装的内存增加了一倍，因此这很可能是主要因素。直觉上，我们可能期望更多的内存总能提高性能，但情况并非总是如此，因为优化器可能开始倾向于具有更多散列、排序和扫描的计划，而不是嵌套循环和索引查找。

更多信息请看我之前的回答：

• UAT 和 PROD 服务器上执行计划的差异

20GB 的设置通常不足以证明设置启动跟踪标志 2335（如该答案中所述）的合理性，但只有测试才能证明这一点。

作为一个潜在的快速修复方法，您可以考虑设置max server memory回以前的值，同时识别在新服务器上退化的查询计划，并使用正常的调优方法纠正根本原因。如果这听起来很笼统和笨拙，我深表歉意，但现实是性能不佳有很多可能的原因，并且有既定的方法来识别和纠正最常见的问题。我在这里回答的目标是让您的系统回到接近 2005 年的位置。

使用 10Gb 内存运行一小时后：最后一个区别是 tempdb 的大小，它比旧服务器上的要大，并且现在使用了大部分内存，导致页面预期寿命几乎为 490。

该tempdb的数据库可能已经预先生长至容纳结束了从存储器溢出排序和散列; 现在可能不需要那么大了。在tempdb的数据库不从任何其他数据库使用内存中的任何不同。PLE“几乎没有 490”作为英语句子没有任何意义。

将最大服务器内存设置回 10GB 的重点是鼓励类似于 2005 安装的执行计划，从而将性能恢复到可接受的水平。你不会说它是否有帮助。在这个阶段，您很可能需要当地的专业支持；我认为我们已经达到了问答格式可以合理完成的极限。