SQL Server Rebuild/Reorganize Fragmented Indexes 導致 CRC 錯誤或一致性錯誤
在我們的測試實驗室中，我一直在嘗試不同的工作，以防止我們的關鍵索引變得過於分散。
我目前正在使用此處描述的方法：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。
作業系統在讀取期間向 SQL Server 返回錯誤 23（數據錯誤（循環冗餘校驗）。）
這表明作業系統檢測到從硬碟本身讀取數據的問題。當數據寫入文件系統時，作業系統會為每個寫入的塊計算一個 CRC 碼；當該數據隨後被讀回時，作業系統再次對讀取的數據執行 CRC 操作，並將其與儲存在文件系統中的 CRC 進行比較。如果這兩個 CRC 程式碼不匹配，作業系統會報告錯誤 23。如果驅動器本身或其他一些組件（如主機板或驅動器控制器）沒有硬體問題，我會感到非常驚訝。
WITH (ONLINE=ON)在 SQL Server 企業版中對此問題沒有任何影響。線上索引操作與離線索引操作在作業系統層沒有區別；根據需要讀取和寫入數據以重建或重新創建索引。