這是我在Windows錯誤日誌中看到的：
SQL Server 偵測到基於邏輯一致性的 I/O 錯誤：校驗和不正確（預期：0x19fedd20；實際：0x19fed5e3）。它發生在讀取檔案「D:\mssql\local_repository_pbdiffimport.mdf」中偏移量 0x00000000dc8000 處的資料庫 ID 6 中的頁面 (1:1764) 期間。 SQL Server 錯誤日誌或系統事件日誌中的其他訊息可能會提供更多詳細資訊。這是一個嚴重的錯誤情況，威脅資料庫的完整性，必須立即修正。完成完整的資料庫一致性檢查 (DBCC CHECKDB)。此錯誤可能由多種因素引起；有關詳細信息，請參閱 SQL Server 線上叢書。
我跑了
dbcc 檢查資料庫
這告訴我我應該使用選項 REPAIR_ALLOW_DATA_LOSS 進行恢復，所以我最終跑了
DBCC CHECKDB（my_db_name，REPAIR_ALLOW_DATA_LOSS）沒有_INFOMSGS
但這導致大約 2,000 行丟失。我恢復了備份，但現在我擔心這種情況會再次發生，因為大約兩週前我們在同一個資料庫中已經出現了一致性問題，但後來它發生在索引中（重新創建的索引解決了問題） 。
我們已經調查了這些光碟 - RAID5 看起來不錯，沒有錯誤，而且所有光碟檢查實用程式都沒有發現任何硬體問題。
這可能是由作業系統 (Windows Server 2003) 或 MSSQL (MSSQL Server 2005) 引起的嗎？
答案1
一致性可能是由硬體或軟體的任何因素引起的。查看 SQL 日誌以調查可能導致問題的原因。
我的建議：
- 確保資料庫選項 Page_Verify 設定為 CHECKSUM。這會在所有寫入發生之前對其進行驗證，並且是 SQL Server 2005 上的預設設定。
- 每天備份或一天多次備份（根據需要）
- 設定維護計劃以每天檢查資料庫的一致性
- 使用修補程式更新您的 Windows Server 和 Sql Server，以及第三軟體。
- 讀 ”有效資料庫維護的重要技巧”，因為它更詳細地解釋了我的大部分建議。
我強烈推薦這篇文章，因為它是為了幫助不知道管理資料庫伺服器的系統管理員而寫的。
答案2
您的系統事件日誌中可能報告了硬體事件，您應該調查它們。
運行 SQLIOSIM 以對磁碟施加壓力 24 小時以上。如果 SQLIOSIM 報告錯誤，您必須聯絡硬體供應商進行調查。它可以來自磁碟、來自 RAID 陣列、來自驅動程式。作業系統和 SQL 是最不可能的罪魁禍首。
答案3
絕對不是 SQL Server 問題（嗯，非常非常非常不可能）。也不太可能是作業系統問題 - 只是因為垃圾寫入太明顯而無法作為錯誤長期存在。
這嚴重指出了硬體的方向。 RAM（您確實使用 ECC？）可能是罪魁禍首，任何其他類型的相關問題（RAID 控制器？光碟？）