MSSQLSERVER_833
详细信息
| Attribute | 值 |
|---|---|
| 产品名称 | SQL Server |
| 事件 ID | 833 |
| 事件来源 | MSSQLSERVER |
| 组件 | SQLEngine |
| 符号名称 | BUF_LONG_IO |
| 消息正文 | SQL Server 已 %d 次遇到了针对数据库 [%ls] (%d) 中文件 [%ls] 的、所需完成时间超过 %d 秒的 I/O 请求。 OS 文件句柄是 0x%p。 最新的长时间 I/O 操作的偏移量是: %#016I64x。 |
解释
该消息指示 SQL Server 已从磁盘发出读取或写入请求，并且表明该请求发回所用的时间已超过 15 秒。 SQL Server 报告此错误，并指示 I/O 子系统出现问题。 数据库管理系统（如 SQL Server）依赖于文件输入和输出（I/O）操作时间线。 以下任一项可能会导致 I/O 操作停滞或停止，并对 SQL Server 响应能力和性能产生不利影响：
- 硬件故障
- 配置不当的硬件
- 固件设置
- 筛选器驱动程序
- 压缩
- Bug
- I/O 路径中的其他条件
这些 I/O 问题可能会导致发生以下行为：
- 阻塞。
- 闩锁争用和超时。
- 响应时间较长。
- 资源边界的延伸。
- 你可能还会注意到与此消息相关的其他症状，例如：
- PAGEIOLATCH 等待时间较高。
- 系统事件日志中的警告或错误。
- 系统监视器计数器中磁盘延迟问题的指示。
当 I/O 操作挂起 15 秒或更长时间时，SQL Server 将执行以下步骤：
检测操作是否已挂起。
将信息性消息写入 SQL Server 错误日志，如“详细信息”部分所述。
下表提供了此信息性消息的不同部分的说明：
| 消息文本 | 说明 |
|---|---|
| <出现次数> （秒） | 未在 15 秒内完成读取或写入操作的 I/O 请求数。 |
| 文件信息 | 完整的文件名、数据库名称和数据库标识 （DBID） 编号。 |
| 句柄 | 文件的操作系统句柄。 可以将操作系统句柄用于调试器或其他实用工具，以帮助跟踪 I/O 请求数据包（IRP）请求。 |
| 偏移量 | 上次停滞的 I/O 操作或上次停止的 I/O 操作的偏移量。 可以将偏移量用于调试器或其他实用工具，以帮助跟踪 IRP 请求。 注意： 将信息性消息写入 SQL Server 错误日志时，I/O 操作可能不再停滞或停止。 |
可能的原因
信息性消息指示当前负载可能遇到以下条件之一：
- 由于 I/O 子系统（SAN、NAS 和直接连接）配置错误或硬件容量已达到，工作负荷超过了 I/O 路径功能。
- 工作负荷超过当前系统功能，例如 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 的很长一段时间。 有关详细信息，请参阅“ 详细信息 ”部分。
用户操作
通过执行以下步骤排查此错误：
- 检查系统事件日志中是否显示与硬件相关的错误消息。
- 检查特定于硬件的日志（如果可用）。 使用必要的方法和技术来确定操作系统、驱动程序或 I/O 硬件延迟的原因。
- 更新所有设备驱动程序和固件，或者执行与 I/O 子系统关联的其他诊断。
- 筛选器驱动程序（例如防病毒程序）可能会降低磁盘访问速度。 若要提高访问速度，请从活动病毒扫描中排除错误消息中指定的 SQL Server 数据文件。 有关详细信息，请参阅如何选择要在运行 SQL Server 的计算机上运行的防病毒软件（microsoft.com）。
- 使用 fltmc.exe 命令行实用工具查询系统上安装的所有筛选器驱动程序，并了解它在数据库文件的存储路径上执行的函数。
- 使用性能监视器检查以下计数器：
- Average Disk Sec/Transfer
- Average Disk Queue Length
- Current Disk Queue Length
- 还可以使用 Storport ETW 日志记录等设施来度量对磁盘单元发出的请求的延迟。 另一种类似的磁盘 I/O 故障排除工具包是作为 Windows Performance Recorder 的内置配置文件提供的。
- 监视 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 检测，尽管不建议这样做。
可以使用跟踪标志 830 禁用已停止和停滞 I/O 的检测。 若要在每次启动 SQL Server 时启用此标志，请使用 -T830 启动参数。 若要禁用当前正在运行的 SQL Server 实例的检测，请使用以下语句：
dbcc traceon(830, -1)
此设置仅在 SQL Server 进程生存期有效。
注意
仅报告一次停止或停滞的 I/O 请求。 例如，如果消息报告 10 个 I/O 请求已停止，则不会再次发生这 10 个报告。 如果下一条消息报告 15 个 I/O 请求已停止，则表示 15 个新的 I/O 请求已停止。
跟踪 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 处理请求并快速完成。 为了帮助防止出现此类停滞情况，硬件制造商建议在故障转移前重试五秒的设置。
示例 2：筛选器驱动程序干预
许多防病毒软件程序和备份产品都使用 I/O 筛选器驱动程序。 这些 I/O 筛选器驱动程序将成为 I/O 请求堆栈的一部分，并有权访问 IRP 请求。 Microsoft 产品支持服务在筛选器驱动程序实现中创建停滞的 I/O 条件或停滞的 I/O 条件的 bug 中出现了各种问题。
其中一种情况是用于备份处理的筛选器驱动程序，它允许备份备份发生备份时打开的文件。 系统管理员在文件备份选择中包含 SQL Server 数据文件目录。 备份发生时，备份会尝试在备份启动时收集文件的正确映像。 执行此操作会延迟 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 时，总 I/O 时间将增加。 对于远程镜像安装，可能会涉及网络重试。 当驱动器故障发生并且正在重新生成 RAID 系统时，I/O 模式也可以中断。
解决方案
需要严格的配置设置，以减少镜像延迟或突袭重新生成操作。
示例 5：压缩
Microsoft 不支持压缩驱动器上的 SQL Server 数据文件和日志文件。 NTFS 压缩对 SQL Server 不安全，因为 NTFS 压缩会中断预写日志记录 （WAL） 协议。 NTFS 压缩还需要增加每个 I/O 操作的处理。 压缩会创建“一次一个”的行为，导致出现严重的性能问题。
解决方案
若要解决此问题，请取消压缩数据和日志文件。
有关详细信息，请参阅 对压缩卷上的数据库的支持。
其他数据点
PAGEIOLATCH_* 和写入日志等待sys.dm_os_wait_stats动态管理视图（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 等待类型存储库
参考
SQL Server 要求系统支持“保证传送到稳定媒体”，如 SQL Server I/O 可靠性计划要求中所述。 有关 SQL Server 数据库引擎的输入和输出要求的详细信息，请访问数据库引擎输入/输出要求。
有关 I/O 错误的详细信息，请参阅 Microsoft SQL Server I/O 基础知识，第 2 章。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈