我们在 DEV/QA/PROD SQL 2017 Enterprise 服务器上遇到了看似随机的错误 824。服务器运行几乎相同的代码，通过 ETL 流程将相同的日常文件摄取到我们的数据仓库中。这些错误是在 2022 年 5 月左右首次发现的，但由于日志清理，我们无法确定（供应商提供的）ETL 流程是否正在捕获这些错误、记录警告并继续处理而不是失败！
DEV/QA 已修补到 CU30（最新的 CU）——这种情况仍然存在。CU22 的生产落后了几个补丁，计划在未来几周内进行修补。
例子：
SQL Server 检测到基于逻辑不一致的 I/O 错误：校验和不正确（预期为 0xc30164e7；实际为 0x9f2bc675c）。它发生在读取文件“H:\tempdb_mssql_6.ndf”中偏移量 0x0000027de40000 处的数据库 ID 2 中的页 (7:1306400) 期间。
如前所述，这种情况在我们所有的环境中都是随机发生的。所有服务器都是虚拟化的。DEV/QA 都使用相同的 SAN。生产位于不同数据中心的单独 SAN 上。我没有 SAN 设备品牌/型号的详细信息。
在大多数情况下，当发生这种情况时，它似乎主要在 tempdb 中（但并非总是如此）。此外，suspect_pages 通常是空的。这种情况似乎在周六发生得更频繁，因为我们连续发生了 3-4 次。
另请注意，错误中列出的预期/实际值通常是相同的 - 但并非总是如此。
还注意到，特定的存储过程似乎更容易引发此错误，但是，它已经发生在 ETL 作业中的多个其他位置，再次影响不同的数据库。似乎触发此错误的存储过程最常添加一个 PERSISTED 计算列，然后添加一个基于该计算列的 ROW_NUMBER() - 到 5 个表，大小范围从 200K 到 750 万行。我们昨天（在 QA 中）修改了此过程，以限制使用 ROW_NUMBER() 值更新的行数（仅当 rownum=1 时），并将更新从一次性全部更改为 25K 批量方法。今天在 QA 中再次发生该错误 - 因此我们删除了计算列上的 PERSISTED 选项。我们实际上正在尝试在质量检查中阻止这种情况，因为它似乎受到的影响最大。
DBCC CHECKDB …