在我们的测试实验室中，我一直在尝试不同的工作，以防止我们的关键索引变得过于分散。
我目前正在使用此处描述的方法：sys.dm_db_index_physical_stats（在示例-> D 部分下：在脚本中使用 sys.dm_db_index_physical_stats 来重建或重组索引）。
基本上每小时我都会查询dm_db_index_physical_stats动态管理视图，如果索引的碎片率在 5% 到 30% 之间，我会重新组织它，如果它的碎片率大于 30%，我会重建它。在我们的大部分测试中，它似乎工作正常，但是，有两次我遇到了计划作业失败并出现错误的问题：
操作系统在文件“C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\database.mdf”中的偏移量 0x00000eae3b2000 处读取期间向 SQL Server 返回错误 23（数据错误（循环冗余检查）。） .
SQL Server 错误日志和系统事件日志中的其他消息可能会提供更多详细信息。
这是威胁数据库完整性的严重系统级错误情况，必须立即纠正。
完成完整的数据库一致性检查 (DBCC CHECKDB)。这个错误可能是由许多因素引起的；有关详细信息，请参阅 SQL Server 联机丛书。[SQLSTATE HY000]（错误 823）
当我在我DBCC CHECKDB的一个索引中报告问题时，我能够解决此问题的唯一方法是使用
DBCC CHECKDB ('dbname', REPAIR_ALLOW_DATA_LOSS)
我不是很肯定，但我怀疑这个错误是由于在测试实验室中运行负载测试时重建或重组索引引起的。
我四处搜索，发现没有其他人报告与重建索引相关的一致性错误。您可以在我的博客文章中查看有关我的问题的更多信息：SQL Server Index Corruption: CRC Error & DBCC CHECKDB
我调整索引的方法有缺陷吗？我不应该尝试在“实时”数据库上重建索引（当流量达到它时）？我是否应该使用 SQL Server Enterprise Edition 的重建索引的功能 (online=on)？任何帮助表示赞赏。
我正在运行 SQL Server 2008 R2 Standard。
这表明操作系统检测到从硬盘本身读取数据的问题。当数据写入文件系统时，操作系统会为每个写入的块计算一个 CRC 码；当该数据随后被读回时，操作系统再次对读取的数据执行 CRC 操作，并将其与存储在文件系统中的 CRC 进行比较。如果这两个 CRC 代码不匹配，操作系统会报告错误 23。如果驱动器本身或其他一些组件（如主板或驱动器控制器）没有硬件问题，我会感到非常惊讶。
WITH (ONLINE=ON)在 SQL Server 企业版中对此问题没有任何影响。在线索引操作与离线索引操作在操作系统层没有区别；根据需要读取和写入数据以重建或重新创建索引。那么它很好，然后从最新的有效备份中恢复。确保在应用之前使用restore verifyonly检查备份的一致性。