临时数据库中的高写入延迟

Question

我目前处于一种“偶然的 dba”角色。我试图监视和改进数据库。我一直在使用 Udemy 课程中的脚本（我可以发布，但可能有点长）。我每小时运行它 5 分钟来捕获磁盘延迟样本，我不确定这是否是一个好方法。但是我注意到 tempdb 中有很多巨大的峰值，例如 300+ 毫秒，但通常会低一点。

tempdb 与数据文件位于同一磁盘上。我将建议使用单独的驱动器，理想情况下是 SSD，但目前我已将 tempdb 数据文件拆分为 4 个文件并使它们相当大，因此它们不需要经常自动增长。这种变化是否会造成峰值，不幸的是没有基线，因为所做的更改是为了改善某些问题。或者 tempdb 问题仅仅是性能不佳的第 3 方应用程序。任何建议将不胜感激！

这是 sp_blitz 降价

我已经隐藏了引用特定公司的任何数据库名称。

优先级 1：备份：

• 备份到数据库所在的同一驱动器 - 过去两周在驱动器 D:\ 上完成了 85 次备份，数据库文件也存在于此。如果该阵列出现故障，这表示严重的风险。

• 无日志备份的完全恢复模式

  • COMPCRM - 上周未备份 500.00MB 的日志文件。

  • ClientManager - 上周没有备份 2.25MB 的日志文件。

  • CRMSelfService - 上周未备份 2.31MB 的日志文件。

  • VOIP.SDC - 上周没有备份 2362.81MB 的日志文件。

  • Elmah - 上周没有备份 20.94MB 的日志文件。

  • hMailServer - 上周没有备份 2.06MB 的日志文件。

  • NLog - 上周未备份 117.63MB 的日志文件。

  • ReportServer - 上周未备份 6.25MB 日志文件。

  • ACC_COMP_SYS_Be - 上周未备份 2599.13MB 日志文件。

  • ACC_COMP_SYS_DW - 上周未备份 32.78MB 日志文件。

  • ACC_COMPSYS_Y2013 - 上周未备份 2599.13MB 日志文件。

  • ACC_CRM - 上周未备份 63.00MB 的日志文件。

  • ACCLogViewer - 上周未备份 4.00MB 日志文件。

优先级 1：可靠性：

• 超过 2 周的最后一次良好的 DBCC CHECKDB - 最后一次成功的 CHECKDB：从不。

  • COMPCRM

  • 客户经理

  • CRM自助服务

  • VoIP.SDC

  • 艾尔玛

  • 邮件服务器

  • 掌握

  • 模型

  • 数据库

  • 日志

  • 报表服务器

  • 报表服务器临时数据库

  • ACC_COMP_SYS - 最后一次成功的 CHECKDB：2016-10-17 13:29:27.837

  • ACC_COMP_SYS_Bs - 上次成功的 CHECKDB：从不。

  • ACC_COMP_SYS_SUPPORT

  • ACC_COMP_SYS_DW

  • ACC_COMP_SYS_Test - 最后一次成功的 CHECKDB：2016-10-17 13:29:27.837

  • ACC_COMPSYS_Snapshot_2016 - 上次成功的 CHECKDB：从不。

  • ACC_COMPSYS_TEST

  • ACC_COMPSYS_Y2013

  • ACC_COMPSYS_Y2014

  • ACC_COMPSYS_Y2015

  • ACC_CRM

  • ACC_Demo_Data

  • ACC配置

  • ACCLogViewer

优先级 10：性能：

• 启用自动收缩

  • ACC_COMP_SYS_DW - 数据库 [ACC_COMP_SYS_DW] 已启用自动收缩。此设置会显着降低性能。

  • ACC_Demo_Data - 数据库 [ACC_Demo_Data] 已启用自动收缩。此设置会显着降低性能。

优先级 20：可靠性：

• 不支持的 SQL Server 版本 - Microsoft 不再支持版本 10.50.1617.00。您需要应用服务包。

优先级 50：可靠性：

• 页面验证不是最佳的

  • COMPCRM - 数据库 [COMPCRM] 没有用于页面验证的 NONE。SQL Server 可能更难识别存储损坏并从中恢复。考虑使用 CHECKSUM 代替。

  • ACC_COMP_SYS_DW - 数据库 [ACC_COMP_SYS_DW] 具有用于页面验证的 TORN_PAGE_DETECTION。SQL Server 可能更难识别存储损坏并从中恢复。考虑使用 CHECKSUM 代替。

  • ACC_Demo_Data - 数据库 [ACC_Demo_Data] 具有用于页面验证的 TORN_PAGE_DETECTION。SQL Server 可能更难识别存储损坏并从中恢复。考虑使用 CHECKSUM 代替。

• 远程 DAC 已禁用 - 未启用对专用管理连接 (DAC) 的远程访问。当 SQL Server 没有响应时，DAC 可以使远程故障排除变得更加容易。

• 事务日志大于数据文件

  • VOIP.SDC - 数据库 [VOIP.SDC] 有一个 2 GB 的事务日志文件，大于总数据文件大小。这可能表明事务日志备份没有被执行或执行得不够频繁。

  • ACC_COMP_SYS_Bvs - 数据库 [ACC_COMP_SYS_Bs] 有一个 2 GB 的事务日志文件，大于总数据文件大小。这可能表明事务日志备份没有被执行或执行得不够频繁。

  • ACC_COMPSYS_Y2013 - 数据库 [ACC_COMPSYS_Y2013] 有一个 2 GB 的事务日志文件，大于总数据文件大小。这可能表明事务日志备份没有被执行或执行得不够频繁。

优先级 100：性能：

• 一个查询的多个计划 - 计划缓存中的单个查询有 590 个计划 - 这意味着我们可能存在参数化问题。

优先级 150：性能：

• 驱动器 D 上的存储写入速度慢 - 此驱动器上至少有一个数据库的平均写入时间超过 100 毫秒。对于特定的数据库文件速度，请从信息链接运行查询。

优先级 200：备份：

• MSDB 备份历史记录未清除 msdb - 数据库备份历史记录保留回 2011 年 4 月 21 日上午 11:46

优先级 200：信息性：

• 代理作业同时启动 - 多个 SQL Server 代理作业配置为同时启动。有关详细的时间表列表，请参阅 URL 中的查询。

• 备份压缩默认关闭 - 最近发生了未压缩的完整备份，并且未在服务器级别打开备份压缩。备份压缩包含在 SQL Server 2008R2 及更新版本中，即使在标准版中也是如此。我们建议默认打开备份压缩，以便临时备份得到压缩。

优先级 200：监控：

• 没有失败的代理工作电子邮件

  • 作业 COMPSYS_CoreDatabaseBackup 尚未设置为在失败时通知操作员。

  • 作业 PerfLog 尚未设置为在失败时通知操作员。

  • 作业 Re-index ACC_COMPSYS_Live.Subplan_1 尚未设置为在失败时通知操作员。

  • 作业 syspolicy_purge_history 尚未设置为在失败时通知操作员。

• 无损坏警报 - SQL Server 代理不存在针对错误 823、824 和 825 的警报。这三个错误可以为您提供有关早期硬件故障的通知。启用它们可以防止你很多心碎。

• 没有针对严重性 19-25 的警报 - 严重性级别 19 到 25 不存在 SQL Server 代理警报。这些是一些非常严重的 SQL Server 错误。知道这些正在发生可能会让您更快地从错误中恢复。

• 未配置故障安全操作员 - 此服务器上未配置故障安全操作员。这是一个好主意，以防万一 [msdb] 数据库存在阻止警报的问题。

• 未配置/启用操作员 - 未配置 SQL Server 代理操作员（电子邮件）。这是一种免费、简单的方法，可以在监控系统发现损坏、作业失败或重大中断之前获得通知。

• 未配置所有警报 - 未配置所有 SQL Server 代理警报。这是一种免费、简单的方法，可以在监控系统发现损坏、作业失败或重大中断之前获得通知。

优先级 200：非默认服务器配置：

• Agent XPs - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

• 并行成本阈值 - 此 sp_configure 选项已更改。它的默认值为 5，已设置为 50。

• 最大并行度 - 此 sp_configure 选项已更改。其默认值为 0，已设置为 4。

• 最大服务器内存 (MB) - 此 sp_configure 选项已更改。其默认值为 2147483647，已设置为 9000。

优先级 200：性能：

• 旧兼容级别

  • ACC_COMP_SYS_DW - 数据库 ACC_COMP_SYS_DW 的兼容性级别为 80，当尝试运行具有较新 T-SQL 功能的查询时，这可能会导致不需要的结果。

  • ACC_Demo_Data - 数据库 ACC_Demo_Data 的兼容性级别为 90，当尝试运行具有较新 T-SQL 功能的查询时，这可能会导致不需要的结果。

优先级 210：非默认数据库配置：

• ANSI NULL 默认启用 COMPCRM - 此数据库设置不是默认设置。

• Read Committed Snapshot Isolation Enabled VOIP.SDC - 此数据库设置不是默认设置。

优先级 240：等待统计：

• 未检测到重要等待 - 该服务器可能只是闲置，或者最近有人可能清除了等待统计信息。

优先级 250：服务器信息：

• 默认跟踪内容 - 默认跟踪保存 2016 年 10 月 12 日凌晨 3:28 至 2016 年 11 月 4 日上午 10:37 之间的 559 小时数据。默认跟踪文件位于：D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log

• 驱动器 C 空间 - C 驱动器上有 177886.00MB 可用空间

• 驱动器 D 空间 - D 驱动器上有 379091.00MB 可用空间

• 驱动器 F 空间 - F 驱动器上有 3575387.00MB 可用空间

• 硬件 - 逻辑处理器：4。物理内存：16GB。

• 硬件 - NUMA 配置 - 节点：0 状态：ONLINE 在线调度程序：4 离线调度程序：0 处理器组：0 内存节点：0 内存 VAS 保留 GB：16

• 服务器上次重启 - 2016 年 10 月 12 日凌晨 2:27

• 服务器名称 - SVR01

• SQL Server 上次重启 - 2016 年 10 月 17 日晚上 8:14

• SQL Server 服务 - 版本：10.50.1617.0。补丁级别：RTM。版本：标准版（64 位）。AlwaysOn 已启用：0。AlwaysOn 管理器状态：0

优先级 254：运行日期：

• 船长的日志：确定某事某事...

Answer 1

与其选择随机指标并尝试调整它们，不如退后一步询问 SQL Server，“您一直在等待什么？”

我最喜欢的方法是使用开源工具 sp_Blitz（因为，呃，我写了它。）你可以从 FirstResponderKit.org 下载它，运行 sp_Blitz.sql 脚本将它安装到你选择的数据库中。

当你用简单的旧运行它时：

EXEC sp_Blitz @CheckServerInfo = 1

它为您提供了一个优先的问题列表，供您检查会影响性能的问题。

在优先级 240 附近，您会找到有关等待统计信息（优先级 240 左右）的部分，它告诉您 SQL Server 一直在等待什么。这就是我首先关注的内容，以确定要更深入地检查哪些指标。例如，如果您最大的等待类型是 PAGEIOLATCH，这意味着您正在等待从数据文件中读取数据页 - TempDB 存储速度并不重要。（别担心，你不必知道那些神秘的等待类型是什么意思——只需点击输出中的更多信息链接。）

如果您想从 Stack 人员那里获得解释结果的帮助，您也可以像这样运行它：

EXEC sp_Blitz @OutputType = 'markdown'

这将以 Markdown 格式导出结果，这是一种文本格式，您可以将其复制/粘贴到 StackOverflow 问题中。