數據庫完整性檢查

爲了主動發現數據庫側頁損壞，保證數據庫邏輯和物理完整性，計劃每週六上午6點，針對生產主庫上的全部系統和用戶數據庫執行DBCC CHECKDB，將結果記錄到表中。

如下爲理論依據：

SQL Server數據庫能夠檢測出頁損壞，此時，具體的表現形式可能爲下述三種錯誤的一種：

• 823錯誤，也就是所謂的硬IO錯誤，能夠理解爲SQL Server但願讀取頁，而Windows告訴SQL Server，沒法讀取到該頁。

• 824錯誤，也就是所謂的軟IO錯誤，能夠理解爲SQL Server已經讀取到該頁，但經過計算CheckSum等值發現不匹配，所以SQL Server認爲該頁已經被損壞。

• 825錯誤，也就是所謂Retry錯誤。

SQL Server發現錯誤的方法有兩種，分別爲在讀取頁時和在備份時（本質上也是讀取頁）。但若是咱們但願對於數據一致性的檢查更加的全面，那咱們應該按期使用CheckDB來檢查數據的一致性，而不至於在生產時間數據被讀取時才能發現錯誤。

CheckDB命令在企業版中會使用多線程來進行，會對整個數據庫進行一致性檢查，在該過程當中，使用了內建數據庫快照的方式進行，所以不會形成阻塞，但CheckDB會消耗大量的CPU、內存和IO。所以CheckDB要選擇在維護窗口時間或是系統閒時進行。

實際上，CheckDB是一套命令的彙總，經過執行下列操做檢查指定數據庫中全部對象的邏輯和物理完整性：

• 初次檢查系統表

• 分配單元檢查（DBCC CHECKALLOC）

• 完整檢查系統表

• 對全部表進行一致性邏輯檢查（DBCC CHECKTABLE）

• 元數據檢查（DBCC CHECKCATALOG）

• SSB檢查

• 索引視圖、XML索引等檢查

微軟最佳實踐建議

「建議您使用 PHYSICAL_ONLY 選項，以即可以頻繁檢查生產系統。 使用 PHYSICAL_ONLY 能夠極大地縮短對大型數據庫運行 DBCC CHECKDB 的運行時間。 同時建議您按期運行沒有選項的 DBCC CHECKDB。 應當以什麼頻率執行這些運行任務將取決於各個企業及其生產環境。

」引用自：

https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql

成熟的方案

能夠使用 https://ola.hallengren.com/

實現備份、完整性檢查、索引和統計信息維護整套方案。