SQL Server 2016企业版性能不佳

抱歉，很长，但是我想给您尽可能多的信息，以便对分析有所帮助。

我知道有几个帖子有类似的问题，但是，我已经关注了网上发布的这些帖子和其他信息，但是问题仍然存在。

我在SQL Server中遇到严重的性能问题，这使用户发疯。这个问题持续了好几年，直到2016年底由另一个实体管理，从2017年开始由我管理。

在2017年中，我能够按照Microsoft SQL Server 2012性能仪表板报告中指示的索引提示解决问题。效果是立竿见影的，听起来像魔术。在过去的日子里，几乎总是100％的处理器变得超级宁静，并且用户的反馈声也很高。甚至我们的ERP技术人员也很高兴，因为通常需要20分钟才能获得某些清单，最后他可以在几秒钟内完成。

但是，随着时间的流逝，它开始慢慢恶化。我避免创建更多索引，因为担心过多的索引会降低性能。但是在某些时候，我不得不删除那些没用的东西，并创建Performance Dashboard向我建议的新东西。但没有影响。

在ERP中进行保存和咨询时，感觉到的缓慢本质上。

我有专用于SQL Server 2016 Enterprise（64位）的Windows Server 2012 R2，具有以下配置：

• 处理器：Intel Xeon CPU E5-2650 v3 @ 2.30GHz
• 记忆体：84 GB
• 在存储方面，服务器具有专门用于操作系统的卷，专门用于数据的卷和专门用于日志的卷。
• 17个数据库
• 使用者：
  • 在最大的数据库中，大约有113个用户并发连接
  • 另外约有9位使用者
  • 其中两个是3 + 3
  • 其余各只有1个用户
  • 我们有一个网站，它也为较大的数据库编写数据，但是使用情况不那么常规，应该有大约20个用户。
• 数据库大小：
  • 最大的数据库有290 GB
  • 第二大有100GB
  • 第三大有20 GB
  • 第四个14 GB
  • 其余各只有3 GB以上

这是生产实例，但我们也有一个开发实例，我相信可以为此忽略它，因为在大多数情况下，我是唯一的连接对象，但是即使没有连接，该问题也会不断发生。

处理器几乎总是这样：

我们的例程在夜间运行（没有问题），而某些例程在白天运行。

用户通过远程桌面连接到由ODBC 32配置为访问SQL Server的其他计算机。

服务器所在的数据中心以及我所在的位置都具有100/100 Mbps。大多数站点通过MPLS链接，而其他站点则通过IPSec（从FO到4G）链接。提供商进行了许多分析，电路还可以。

缓存命中率为99％（用户请求和用户会话）

等待看起来像这样：

我已经使用Perfmon收集了数据，如果对您的分析有所帮助，我将获得结果-就个人而言，我没有从分析中得出任何结论。

我依靠您的支持来解决此问题，可以为您提供解决该问题所需的信息。

非常感谢你。

这是sp_blitz降价促销（我用假名替换了公司名称）：

优先级1：可靠性：

• 过去2周以上的上次好DBCC CHECKDB

  • 主

  • 模型-上一次成功的CHECKDB：2018-02-07 15：04：26.560

  • msdb-上一次成功的CHECKDB：2018-02-07 15：04：27.740

优先级10：效果：

• 带奇数内核的CPU

  • 节点0分配有5个核心。这是非常差的NUMA配置。

  • 节点1分配有5个核心。这是非常差的NUMA配置。

优先级20：文件配置：

• C驱动器上的TempDB tempdb-tempdb数据库在C驱动器上具有文件。TempDB经常会意外地增长，从而使您的服务器面临C驱动器空间用尽并严重崩溃的风险。C通常也比其他驱动器慢得多，因此性能可能会受到影响。

优先级50：可靠性：

• 最近在默认跟踪中记录的错误
  • master-2018-03-07 08：43：11.72登录错误：17892，严重性：20，状态：1. 2018-03-07 08：43：11.72登录登录由于触发执行而无法登录到example_user。[客户：IPADDR]

（注意：由于启用了触发器而限制了用户会话，因此出现许多此类错误-用于ERP许可使用控制）

• 页面验证不是最佳的

  • DATABASE_A-数据库[DATABASE_A]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_B-数据库[DATABASE_B]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_C-数据库[DATABASE_C]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_D-数据库[DATABASE_D]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_E-数据库[DATABASE_E]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_F-数据库[DATABASE_F]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_G-数据库[DATABASE_G]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_H-数据库[DATABASE_H]的NONE用于页面验证。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_I-数据库[DATABASE_I]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_Z-数据库[DATABASE_Z]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_K-数据库[DATABASE_K]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_J-数据库[DATABASE_J]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_L-数据库[DATABASE_L]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_M-数据库[DATABASE_M]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_O-数据库[DATABASE_O]的NONE用于页面验证。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_P-数据库[DATABASE_P]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_Q-数据库[DATABASE_Q]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_R-数据库[DATABASE_R]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_S-数据库[DATABASE_S]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_T-数据库[DATABASE_T]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_U-数据库[DATABASE_U]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_V-数据库[DATABASE_V]的NONE用于页面验证。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

  • DATABASE_X-数据库[DATABASE_X]没有用于页面验证的内容。SQL Server可能很难识别和从存储损坏中恢复。考虑改用CHECKSUM。

• 禁用远程DAC-未启用对专用管理连接（DAC）的远程访问。当SQL Server没有响应时，DAC可以使远程疑难解答变得更加容易。

优先级50：服务器信息：

• 未启用即时文件初始化-考虑启用IFI，以实现更快的还原和数据文件的增长。

优先级100：效果：

• 填充系数已更改

  • DATABASE_A-[DATABASE_A]数据库具有417个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_B-[DATABASE_B]数据库具有318个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_C-[DATABASE_C]数据库具有346个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_D-[DATABASE_D]数据库具有663个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_E-[DATABASE_E]数据库具有335个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_F-[DATABASE_F]数据库具有1705个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_G-[DATABASE_G]数据库具有671个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_H-[DATABASE_H]数据库具有2364个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_I-[DATABASE_I]数据库具有1658个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_Z-[DATABASE_Z]数据库具有673个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_K-[DATABASE_K]数据库具有312个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_J-[DATABASE_J]数据库具有864个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_L-[DATABASE_L]数据库具有1170个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_M-[DATABASE_M]数据库具有382个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_O-[DATABASE_O]数据库具有356个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • msdb-[msdb]数据库具有8个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_P-[DATABASE_P]数据库具有291个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_Q-[DATABASE_Q]数据库具有343个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_R-[DATABASE_R]数据库具有2048个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_S-[DATABASE_S]数据库具有325个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_T-[DATABASE_T]数据库具有322个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_U-[DATABASE_U]数据库具有351个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_V-[DATABASE_V]数据库具有312个对象，填充系数= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • DATABASE_X-[DATABASE_X]数据库具有352个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

  • tempdb-[tempdb]数据库有2个对象，填充因子= 70％。这可能会导致内存和存储性能问题，但也可能阻止页面拆分。

• 一个查询的许多计划-在计划缓存中为单个查询提供了20763个计划-这意味着我们可能存在参数化问题。

• 启用服务器触发器-启用服务器触发器[connection_limit_trigger]。确保您了解触发器的作用-所做的工作越少越好。

• 带RECOMPILE的存储过程

  • master-[master]。[dbo]。[sp_AllNightLog]在存储过程代码中具有WITH RECOMPILE，由于代码的不断重新编译，可能会导致CPU使用率增加。

  • master-[master]。[dbo]。[sp_AllNightLog_Setup]在存储过程代码中具有WITH RECOMPILE，由于代码的不断重新编译，可能会导致CPU使用率增加。

优先级110：效果：

• 没有聚簇索引的活动表

  • DATABASE_A-[DATABASE_A]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_B-[DATABASE_B]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_C-[DATABASE_C]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_E-[DATABASE_E]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_F-[DATABASE_F]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_H-[DATABASE_H]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_I-[DATABASE_I]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_K-[DATABASE_K]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_O-[DATABASE_O]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_Q-[DATABASE_Q]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_S-[DATABASE_S]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_T-[DATABASE_T]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_U-[DATABASE_U]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_V-[DATABASE_V]数据库具有正在被主动查询的堆-没有聚集索引的表。

  • DATABASE_X-[DATABASE_X]数据库具有正在被主动查询的堆-没有聚集索引的表。

优先级150：效果：

（注意：Nany的建议在这里，但是由于字符的限制，我不能包括它们。如果还有其他共享的方法，请指出。）

您给了我们一个很长（非常详细）的问题。现在，您必须解决一个很长的答案。;）

我建议您在服务器上进行几项更改。但是，让我们从最紧迫的问题开始。

一次性应急措施：

在系统上部署索引后性能令人满意，并且性能逐渐下降，这一事实非常有力地暗示您需要开始维护统计信息，并（在较小程度上）要注意索引框架。

作为紧急措施，我建议一次对所有数据库进行一次手动统计更新。您可以通过执行以下脚本来获取必要的TSQL：

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

它是由Tim Ford在mssqltips.com上的博客中提供的，他还解释了为什么更新统计信息很重要。

请注意，这是一项占用大量CPU和IO的任务，不应在繁忙时间执行。

如果这样可以解决您的问题，请不要就此止步！

定期维护：

看一下Ola Hallengren 维护解决方案，然后至少设置以下两项工作：

• 统计信息更新作业（如果可能，每晚）。您可以在代理工作中使用此CMD代码。必须从头开始创建此作业。

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• 索引维护工作。我建议每月执行一次预定的执行。您可以从Ola为IndexOptimize Job提供的默认值开始。

我建议第一份工作单独更新统计信息有几个原因：

• 索引重建将仅更新该索引覆盖的列的统计信息，而索引重组则根本不更新统计信息。Ola将碎片分为三类。默认情况下，将仅重建类别高索引。
• 索引未涵盖的列的统计信息将仅由IndexOptimize作业更新。
• 缓解升序关键问题。

如果保留默认设置，则SQL Server将自动更新统计信息。问题在于阈值（SQL Server 2016几乎没有问题）。当一定数量的行更改时（在SQL Server的较早版本中为20％），统计信息将更新。如果您有大表，那么在更新统计信息之前可能会有很多更改。在此处查看有关阈值的更多信息。

据我所知，由于您正在执行CHECKDB，因此可以像以前一样继续进行操作，或者也可以使用维护解决方案。

有关索引碎片和维护的更多信息，请查看：

SQL Server索引碎片概述

不再担心SQL Server碎片

考虑到您的存储子系统，我建议不要过多地关注“外部碎片”，因为无论如何数据都不会按顺序存储在SAN中。

优化设置

sp_Blitz脚本为您提供了一个不错的清单。

优先级20：文件配置-C驱动器上的TempDB： 与您的存储管理员联系。询问他们C盘是否是SQL Server可用的最快磁盘。如果不是，请将您的tempdb放在...期间。然后检查您有多少个temdb文件。如果答案是一个解决办法。如果它们的大小不相同，请修复两个。

优先级50：服务器信息-未启用即时文件初始化：单击sp_Blitz脚本为您提供的链接并启用IFI。

优先级50：可靠性-页面验证不是最佳的：您应该将其设置回默认值（CHECKSUM）。单击sp_Blitz脚本为您提供的链接，然后按照说明进行操作。

优先级100：性能-填充因子已更改： 问自己，为什么有这么多对象的填充因子设置为70。如果您没有答案，而且没有应用程序供应商严格要求它。将其设置回100％。

这基本上意味着SQL Server在这些页面上将保留30％的空白空间。因此，要获得相同数量的数据（与100％的完整页面相比），您的服务器必须读取30％以上的页面，并且它们将占用30％的内存空间。经常这样做的原因是为了防止索引碎片。

但是同样，您的存储空间还是将这些页面保存在不同的块中。所以我将其设置回100％并从那里拿走。

如果每个人都很高兴该怎么办：

• 请参见sp_Blitz的其余输出，并确定是否根据建议更改它们。
• 执行sp_BlitzIndex并查看您创建的索引（如果使用了索引）或可能在其中添加/更改索引的地方。
• 查看您的查询存储数据（由Peter建议）。您可以在此处找到简介。
• 享受DBA应有的摇滚巨星现场表演。;）

不忽略您所有有用且我已应用或将要应用的答案，最大的问题并不容易发现。

在我们上次发送消息后的几天里，问题变得更加严重。

由于我们基于云，因此我和管理基础架构并提供支持的公司都无法访问物理主机。

当我注意到某天处理器的平均负载为20％，而另一些日子却要高得多，超过60％时，尽管工作负载虽然从未完全相同，但是却很相似，这使我感到奇怪。有相同数量的人或多或少地执行相同类型的操作。

本周初，用户开始陷入困境只有几分钟，而只有处理器被勒死。我要求几个用户注销（那些人花费更多的资源，但仍然与众不同），我关闭了链接到数据库的各种服务，最后没有任何改变。我要求支持我们的系统管理员，该系统管理员可以与我们的云人员进行通信以远程访问我的机器，以查看我所看到的内容并帮助我找到一些东西，因为我无法更好地发现问题。

技术人员也没有找到任何东西。他终于开始给我一些原因，那就是其他原因导致了这个问题，而这正是他联系云的时候。在云中，他们什么也没意识到，只是因为在物理主机之间配置了负载平衡，所以支持SQL Server的VM当天在物理主机之间移动了几次。幸运的是，我告诉技术人员确切的日期是什么时候开始出现问题的，恰好是VM上次被移动到一天中其余时间没有离开的物理主机的时间。

如果技术人员没有密切关注这个问题，那么这将是他甚至可以与云人员交谈的那一次，但是当他们看到性能样本时，他们什么也得不到，因为再次，云只看到了CPU数量大约为40/50％的样本，而实际上平均在80％以上，并且经常停留在100％。

现在，计算机位于物理主机上（不在主机之间移动），尽管我们尚未获得理想的性能，但每个人都在工作并提供了更多积极的反馈，因为我们所有用户和所有用户的平均CPU约为20％服务。

同时，我们还将tempdb放在另一个磁盘上（该磁盘位于操作系统磁盘上），并增加了文件，使其与CPU内核数更加一致。

还根据sp_Blitz的建议调整了核心数。

还有一个自动程序，它是根据旧日期整天运行的……并且由于它并没有在我们到达时的早晨结束，并且我们无法检查它是否正在运行，所以我仍然开始手动运行。但是，另一个可能仍在运行，并且在此期间运行了两次。我们更改了日期以减少花费的时间，现在已经是深夜了。但这不是解决方案，因为它是我们在这里描述的许多问题之前解决的。

我们还设法让ERP助手安排了与制造商的会议，因此我们将展示我们的系统并寻求建议，并澄清一些疑问，因为培训视频中的建议与大多数建议相反建议，包括Microsoft本身，例如Priority Boost on和Fill Factor 70％。

由于该应用程序还具有维护屏幕，因此我将寻找这些维护所需的定期性以及在应用程序外部要做的事情。我的想法是使用Ola Hallengren的计划。

我相信Thomas Kronawitter的回答是绝对正确的，并且我正在应用它，但是，我认为此描述对于其他人可能很重要，因为遵循所有良好实践仍然无法解决问题，因为它可能存在于物理主机中。谢谢托马斯。