这是我在Windows错误日志中看到的：
SQL Server检测到基于逻辑一致性的I / O错误：不正确的校验和（预期：0x19fedd20;实际：0x19fed5e3）。 它发生在数据库ID为6的文件'D：\ mssql \ local_repository_pbdiffimport.mdf'中偏移量为0x00000000dc8000的页面（1：1764）的读取期间。 SQL Server错误日志或系统事件日志中的其他消息可能会提供更多详细信息。 这是一个严重的错误条件，威胁数据库的完整性，必须立即纠正。 完成完整的数据库一致性检查（DBCC CHECKDB）。 这个错误可能是由许多因素引起的; 有关更多信息，请参阅SQL Server联机丛书。
我跑了
dbcc checkdb
这告诉我，我应该selectREPAIR_ALLOW_DATA_LOSS恢复，所以我最终跑了
DBCC CHECKDB（my_db_name，REPAIR_ALLOW_DATA_LOSS）WITH NO_INFOMSGS
但是这导致了大约2万行丢失。 我恢复了一个备份，但现在恐怕会再次发生，因为我们在大约两周前在同一个数据库中已经存在一致性问题，但之后它发生在一个索引中（重新创build的索引解决了这个问题）。
我们调查了这些光盘–RAID5看起来不错，没有错误，也没有光盘检查实用程序显示任何硬件问题。
这可能是由操作系统（Windows Server 2003）还是由MSSQL（MSSQL Server 2005）引起的？
一致性可能是由硬件或软件的任何因素造成的。 查看SQL日志来调查可能导致问题的原因。
我的build议：
我推荐这篇文章很多，因为它写的是帮助不知道要pipe理数据库服务器的系统pipe理员。
您可能在系统事件日志中报告了硬件事件，您应该调查它们。
运行SQLIOSIM以将磁盘压出+24小时。 如果SQLIOSIM报告错误，则必须联系硬件供应商进行调查。 它可能来自磁盘，来自RAIDarrays，来自驱动程序。 操作系统和SQL是最不可能的罪魁祸首。
请参阅如何使用SQLIOSim实用程序来模拟磁盘子系统上的SQL Server活动 。
绝对不是一个SQL Server的问题（很好，非常非常不可能）。 也不太可能是一个操作系统的问题 – 只是因为废话写得太明显，不能长久存在的错误。
这严重指向了硬件的方向。 RAM（你使用ECC？）是一个可能的罪魁祸首，以及其他types的相关问题（RAID控制器？光盘？）