SQLServer 错误 833 SQL Server 已 %d 次遇到了针对数据库 [%ls] (%d) 中文件 [%ls] 的、所需完成时间超过 %d 秒的 I/O 请求。 OS 文件句柄是 0x%p。 最新的长时间 I/O 操作的偏移量是: %#016I64x。

详细信息

说明

该消息指示 SQL Server 已从磁盘发出读取或写入请求，并且表明该请求返回所用的时间已超过 15 秒。 SQL Server报告此错误，并指示 I/O 子系统存在问题。 数据库管理系统 (DBMS) （如 SQL Server）依赖于文件输入和输出的及时性 (I/O) 操作。 以下任一项都可能导致 I/O 操作停滞或停止，并SQL Server响应能力和性能产生不利影响：

• 硬件故障
• 硬件配置不正确
• 固件设置
• 筛选器驱动程序
• 压缩
• Bug
• I/O 路径中的其他条件

这些 I/O 问题可能会导致发生以下行为：

• 阻塞。
• 闩锁争用和超时。
• 响应时间较长。
• 资源边界的延伸。
• 你可能还会注意到与此消息相关的其他症状，例如：
  • PAGEIOLATCH 等待时间长。
  • 系统事件日志中的警告或错误。
  • 指示系统监视器计数器中的磁盘延迟问题。

当 I/O 操作挂起 15 秒或更长时间时，SQL Server执行以下步骤：

1. 检测操作已挂起。

2. 将信息性消息写入SQL Server错误日志，如“详细信息”部分所述。

   下表说明了此信息性消息的不同部分：

可能的原因

信息性消息指示当前负载可能遇到以下情况之一：

• 工作负荷超出了 I/O 路径功能，原因可能是 I/O 子系统 (SAN、NAS 和直接附加) 配置错误，或者已达到硬件容量。
• 工作负荷超出了当前的系统功能，例如 I/O、CPU 和 HBA。
• I/O 路径的软件出现故障。 这可能是固件或驱动程序问题。
• I/O 路径的硬件组件出现故障。
• 操作系统级别的性能问题。
• 筛选驱动程序干预数据库文件的 I/O 进程或存储路径。 例如，防病毒程序。

SQL Server记录它发起 I/O 请求的时间，并记录 I/O 完成的时间。 如果时间差为 15 秒或更长时间，则会检测到这种情况。 这也意味着SQL Server不是此消息描述和报告的延迟 I/O 条件的原因。 这种情况称为停止的 I/O。 大多数磁盘请求在磁盘的典型速度内发生。 此典型的磁盘速度通常称为磁盘查找时间。 大多数标准磁盘的磁盘寻道时间是 10 毫秒或更短。 因此，15 秒是系统 I/O 路径返回到SQL Server很长的时间。 有关更多详细信息，请参阅 “详细信息” 部分。

用户操作

通过执行以下步骤排查此错误：

1. 检查系统事件日志中是否显示与硬件相关的错误消息。
2. 检查特定于硬件的日志（如果它们可用）。 使用必要的方法和技术来确定操作系统、驱动程序或 I/O 硬件延迟的原因。
3. 更新所有设备驱动程序和固件，或执行与 I/O 子系统关联的其他诊断。
4. 筛选器驱动程序（例如防病毒程序）可能会减慢磁盘访问速度。 若要提高访问速度，请从活动病毒扫描中排除错误消息中指定的SQL Server数据文件。 有关详细信息，请参阅如何选择要在运行SQL Server (microsoft.com) 计算机上运行的防病毒软件。
   • 使用 fltmc.exe 命令行实用工具 查询系统上安装的所有筛选器驱动程序，并了解它在数据库文件的存储路径上执行的功能。
5. 使用性能监视器检查以下计数器：
   • Average Disk Sec/Transfer
   • Average Disk Queue Length
   • Current Disk Queue Length
6. 还可以使用 Storport ETW 日志记录 等工具来度量对磁盘单元发出的请求的延迟。 另一种类似的磁盘 I/O 故障排除工具包是作为 Windows Performance Recorder 的内置配置文件提供的。
7. 监视 sys.dm_io_virtual_file_stats ，并为存储吞吐量选择合适的存储层和 IOPS。

有关诊断和排查 I/O 问题导致的SQL Server性能问题的引导式演练，请参阅排查 I/O 问题导致的SQL Server性能缓慢问题。

更多信息

I/O 停滞和 I/O 停止

I/O 停滞

停滞 I/O 定义为未完成的 I/O 请求。 I/O 停滞通常表示 IRP 停滞。 若要解决 I/O 停滞情况，通常必须重新启动计算机或执行类似的操作。 I/O 停滞条件通常表示以下问题之一：

• 硬件故障。
• I/O 路径组件中的 bug。

停止的 I/O

停止的 I/O 定义为完成或需要很长时间才能完成的 I/O 请求。 由于以下原因之一，通常会发生 I/O 停止行为：

• 硬件配置。
• 固件设置。
• 需要硬件或软件供应商的帮助才能跟踪和解决的筛选器驱动程序问题。

SQL Server I/O 停止以及 I/O 录制和报告停滞

SQL Server支持部门每年处理许多涉及 I/O 卡住或停滞问题的案例。 这些 I/O 问题以不同的方式显示。 I/O 问题是一些最难诊断和调试的问题，它们需要大量的时间和资源才能从 Microsoft 和客户进行调试。 I/O 请求的报告和记录是按文件设计的。 检测和报告停滞的 I/O 请求是两个单独的操作。

录制

记录操作在SQL Server有两个时刻发生。 第一个是 I/O 操作完成的时间。 第二个时刻是延迟编写器运行时。 延迟编写器运行时，它会检查所有挂起的数据和挂起的日志文件 I/O 请求。 如果 I/O 请求超过 15 秒阈值，则会发生记录操作。

报告

报告的间隔为 5 分钟或更长。 对文件发出下一个 I/O 请求时，会发生报告。 如果发生了记录操作，并且自上次报告发生以来已超过五分钟，则详细信息部分中提到的信息性消息将写入SQL Server错误日志。

15 秒阈值不可调整。 但是，可以使用跟踪标志 830 禁用停止或停滞的 I/O 检测，尽管我们不建议这样做。

可以使用跟踪标志 833 禁用对停滞 I/O 的检测。 若要在每次启动SQL Server时启用此标志，请使用 -T830 启动参数。 若要对当前正在运行的SQL Server实例禁用检测，请使用以下语句：

    dbcc traceon(830, -1)

此设置仅在SQL Server过程的生命周期内有效。

跟踪 I/O 请求数据包 (IRP)

SQL Server使用标准 Microsoft Windows API 调用来读取和写入数据。 例如，SQL Server使用以下函数：

• WriteFile
• ReadFile
• WriteFileScatter
• ReadFileGather

读取或写入请求由 Windows 作为 I/O 请求数据包处理， (IRP) 。 若要确定 IRP 的状态，请使用以下两项功能：

• Windows 支持
• Storport ETW 日志记录

建议检查以下项的任何可用更新：

• The BIOS
• 固件
• 任何其他 I/O 路径组件

在执行其他调试操作之前，请与硬件供应商联系。 调试会话可能涉及第三方驱动程序、固件或筛选器驱动程序组件。

系统性能和查询计划操作

总的来说，系统性能在 I/O 处理中起着关键作用。 在调查 I/O 操作停止或停滞的报告时，应考虑系统的一般运行状况。 过多的负载可能会导致整个系统速度缓慢，包括 I/O 处理。 问题发生时系统的行为可能是确定问题根本原因的一个关键因素。 例如，如果在出现问题时 CPU 使用率增加或保持高位，则可能表明系统进程占用过多的 CPU，导致其他进程受到不利影响。

性能计数器

若要监视 I/O 性能，请检查以下性能计数器以获取特定 I/O 路径信息：

• Average Disk Sec/Transfer
• Average Disk Queue Length
• Current Disk Queue Length

例如，运行 SQL Server 的计算机上的平均磁盘秒/传输时间通常小于 15 毫秒。 如果平均磁盘秒/传输值攀升，则表明 I/O 子系统无法以最佳方式跟上 I/O 需求。

使用性能计数器时要小心，因为SQL Server充分利用了大量推送磁盘队列长度的异步 I/O 功能。 因此，仅较长的磁盘队列长度并不表示存在问题。

在 Windows 系统监视器中，可以查看每个受影响磁盘的计数器“物理磁盘：磁盘字节数/秒”，并将活动速率与每个进程的计数器“进程：IO 数据字节/秒”和“进程：IO 其他字节/秒”进行比较。 执行此操作可以确定一组特定进程是否正在生成过多的 I/O 请求。 Process 对象中其他各种与 I/O 相关的计数器显示更精细的信息。 如果确定SQL Server实例导致服务器上的 I/O 负载过多，请参阅下一节，了解索引和并行度。 有关检测和解决 I/O 瓶颈的详细讨论，请参阅排查 I/O 问题导致的SQL Server性能缓慢问题。

索引和并行度

I/O 的突发通常是因为缺少索引而发生。 此行为可能会严重推送 I/O 路径。 使用索引转弯向导 (ITW) 的传递可能有助于解决系统上的 I/O 压力。 如果查询受益于索引而不是表扫描，或者如果它使用排序或哈希，则系统可以获得以下优势：

• 减少了完成直接为查询带来性能优势的操作所需的物理 I/O。
• 数据缓存中必须翻转的页数更少。 因此，数据缓存中的页面仍与活动查询相关。
• 使用排序和哈希是因为索引可能缺失或统计信息已过期。 可以通过添加一个或多个索引来减少 tempdb 的使用和争用。
• 资源、并行操作或同时减少两者。 由于 SQL Server 不能保证并行执行查询，并且考虑了系统上的负载，因此最好优化所有串行执行查询。 若要优化查询，请打开查询分析器，并将“最大并行度”选项的sp_configure值设置为 1。 如果将所有查询优化为作为串行操作立即运行，则并行执行通常只是一个更好的结果。 但是，通常会选择并行执行，因为数据量很大。 对于缺少索引，可能需要进行较大的排序。 执行排序操作的多个辅助角色将创建更快的响应。 但是，此操作可能会显著增加系统的压力。 来自许多辅助角色的大型读取请求可能会导致 I/O 突发，同时增加 CPU 使用率。 如果添加了索引或发生其他优化操作，通常可以优化查询以更快地运行并使用更少的资源。

SQL Server支持部门提供的实际示例

以下示例已由 SQL Server 支持和 Windows 升级支持处理。 这些示例旨在提供一个参考框架，并帮助设置你对停滞和停滞的 I/O 情况的期望。 它们还提供一个框架，用于了解系统可能受到的影响或响应方式。 没有特定硬件或驱动程序集对另一个硬件或驱动程序构成任何特定风险或增加的风险。 所有系统在这方面都是相同的。

示例 1：停滞 45 秒的日志写入

写入SQL Server日志文件的尝试会定期停滞约 45 秒。 日志写入未及时完成。 此行为会创建导致 30 秒客户端超时的阻塞条件。

应用程序已提交到 SQL Server，提交将停滞为日志写入挂起。 此行为导致查询继续持有锁并阻止来自其他客户端的传入请求。 然后，其他客户端开始超时。这加剧了此问题，因为应用程序不会回滚查询超时时打开的事务。 这会创建数百个持有锁的打开事务。 因此，会发生严重的阻塞情况。

有关事务处理和阻止的详细信息，请参阅以下 Microsoft 知识库文章：224453了解和解决SQL Server阻塞问题

应用程序使用连接池为网站提供服务。 随着更多连接被阻止，网站会创建更多连接。 这些连接将被阻止，循环会继续。

日志写入大约需要 45 秒才能完成。 但是，此时会备份数百个连接。 阻塞问题会导致SQL Server和应用程序的恢复时间过几分钟。 结合应用程序问题，停滞的 I/O 条件会对系统产生非常负面的影响。

分辨率

此问题跟踪到主机总线适配器 (HBA) 驱动程序中的 I/O 请求停滞。 计算机具有多个支持故障转移的 HBA 卡。 当一个 HBA 落后或未与存储区域网络 (SAN) 通信时，“故障转移前重试”超时值配置为 45 秒。 当超时超过时，I/O 请求将路由到第二个 HBA。 第二个 HBA 处理请求并快速完成。 为了帮助防止此类停滞情况，硬件制造商建议将“故障转移前重试”设置为 5 秒。

示例 2：筛选器驱动程序干预

许多防病毒软件程序和备份产品使用 I/O 筛选器驱动程序。 这些 I/O 筛选器驱动程序将成为 I/O 请求堆栈的一部分，并有权访问 IRP 请求。 Microsoft 产品支持服务已发现各种问题，这些问题包括筛选器驱动程序实现中导致 I/O 条件停滞或 I/O 条件停滞的 bug。

其中一个条件是用于备份处理的筛选器驱动程序，该驱动程序允许备份在备份时打开的文件。 系统管理员已在文件备份选择中包含 SQL Server 数据文件目录。 备份发生时，备份会尝试在备份启动时收集文件的正确映像。 执行此操作会延迟 I/O 请求。 当软件处理 I/O 请求时，一次只允许完成一个 I/O 请求。

备份开始时，SQL Server性能急剧下降，因为SQL Server的 I/O 被迫一次完成一个。 一次一个逻辑使得 I/O 操作无法异步执行，这加剧了问题。 因此，当SQL Server预期发布 I/O 请求并继续时，辅助角色将停滞在读取或写入调用中，直到 I/O 请求完成。 筛选器驱动程序的操作有效地禁用处理任务，例如SQL Server预读。 此外，筛选器驱动程序中的另一个 bug 会在过程中一次保留一个操作，即使备份完成也是如此。 还原SQL Server性能的唯一方法是重启SQL Server，以便在不与筛选器驱动程序交互的情况下释放并重新获取文件句柄。

分辨率

若要解决此问题，将从文件备份过程中删除SQL Server数据文件。 软件制造商已更正了使文件处于“一次一个”模式的问题。

示例 3：隐藏错误

许多高端系统都有多通道 I/O 路径来处理负载均衡或类似活动。 Microsoft 产品支持部门发现负载均衡软件出现问题，其中 I/O 请求失败，但软件无法正确处理错误条件。 该软件可以尝试无限次重试。 I/O 操作停滞，SQL Server无法完成指定的操作。 与前面所述的日志写入条件非常类似，在此类条件对系统进行楔形之后，可能会出现许多不良的系统行为。

分辨率

若要解决此问题，请重启SQL Server。 但是，有时需要重启操作系统才能还原处理。 我们还建议你从 I/O 供应商处获取软件更新。

示例 4：远程存储、镜像和 raid 驱动器

许多系统使用镜像或采用类似的步骤来防止数据丢失。 某些使用镜像的系统基于软件，有些系统基于硬件。 Microsoft 支持部门通常会发现这些系统的延迟增加。

当 I/O 在被视为完成之前必须完成时，总 I/O 时间会增加。 对于远程镜像安装，可能会涉及网络重试。 当驱动器发生故障并且正在重新生成 raid 系统时，I/O 模式也可能中断。

分辨率

需要严格的配置设置，以减少镜像或突袭重新生成操作的延迟。

示例 5：压缩

Microsoft 不支持在压缩驱动器上SQL Server数据文件和日志文件。 NTFS 压缩对于SQL Server不安全，因为 NTFS 压缩会中断提前写入日志记录 (WAL) 协议。 NTFS 压缩还要求对每个 I/O 操作进行更多的处理。 压缩会创建“一次一个”的行为，导致出现严重的性能问题。

分辨率

若要解决此问题，请解压缩数据和日志文件。

有关详细信息，请参阅 支持压缩卷上的数据库。

其他数据点

sys.dm_os_wait_stats动态管理视图中的PAGEIOLATCH_* 和写入日志等待 (DMV) 是调查 I/O 路径性能的关键指标。 如果看到大量的 PAGEIOLATCH 等待，则表明 SQL Server 正在等待 I/O 子系统。 一定数量的 PAGEIOLATCH 等待是典型的预期行为。 但是，如果平均 PAGEIOLATCH 等待时间始终大于 10 毫秒，则应调查 I/O 子系统承受压力的原因。 有关详细信息，请参阅以下文档：

• 排查 I/O 问题导致的SQL Server性能缓慢问题
• sys.dm_os_waiting_tasks (Transact-SQL)
• sys.dm_exec_requests
• SQL Server等待类型存储库

参考

• 使用 DISKSPD 测试工作负荷存储性能
• 添加826433 SQL Server诊断以检测由于读取过时或写入丢失而导致的未报告的 I/O 问题
• 日志记录和数据存储算法

SQL Server要求系统支持SQL Server I/O 可靠性计划要求中所述的“保证传送到稳定介质”。 有关SQL Server数据库引擎的输入和输出要求的详细信息，请访问数据库引擎输入/输出要求。

有关 I/O 错误的详细信息，请参阅 Microsoft SQL Server I/O 基础知识，第 2 章。