repair_allow_data_loss 是 DBCC CHECKDB 發現的錯誤的最低修復級別
解決數據庫損壞問題。我正在開發環境中製作副本。有些是損壞的索引，在這種情況下我只是刪除並重新創建它。然而，這些都是值得關注的數據損壞問題。
當我執行時：
DBCC CHECKDB ('DATABASE', REPAIR_ALLOW_DATA_LOSS);…它說：
錯誤已修復
這實際上是否意味著它解決了問題，或者它刪除了“修復”的頁面並且數據失去了？
對象 ID 1899231358，索引 ID 0，分區 ID 124468026277888，分配單元 ID 124468026277888（行內數據類型）：無法處理頁面 (1:10429642)。有關詳細資訊，請參閱其他錯誤。
錯誤已修復。
表錯誤：對象 ID 1518653945，索引 ID 1，分區 ID 72057594166444032，分配單元 ID 71875645566156800（類型 LOB 數據）。
頁 (1:10429980)、槽 0、文本 ID 954358824960 處的行外數據節點被頁 (1:6660634)、槽 10 引用，但在掃描中未看到。
錯誤已修復。
正如您使用的選項所述…您在修復過程中失去了數據
REPAIR_ALLOW_DATA_LOSS在您的情況下，您失去了索引 0 的行內數據。修復成功完成，但這不會使您失去的數據恢復原狀。使用該選項可以修復且不會失去數據的唯一損壞情況是，如果所有損壞都發生在非集群（非行內）數據上。
如果您有以前的備份，則可以恢復損壞的頁面。這取決於您的備份對受影響的頁面沒有相同的損壞，如果您沒有定期執行 checkdb、沒有使用校驗和頁面驗證以及備份的帶有校驗和選項，則很有可能發生這種情況。
查看所涉及的表格，並嘗試弄清楚您是否可以重建失去的內容。否則，祝你好運，您可以嘗試恢復頁面，請參閱：
Jes Schultz Borland如何在 SQL Server Standard 和 Enterprise Edition中恢復頁面
就我的“經驗”而言，repair_allow_data_loss 從未真正解決過問題，它實際上所做的是盡可能多地刪除罪魁禍首，以確保剩下的一切都是一致的。這應該永遠是你擺脫腐敗的最後手段。此外，它還可以刪除那些有價值的約束/業務約束，您的邏輯就是在這些約束/業務約束上設計的，從而使數據庫處於易受攻擊的狀態。
MS在這裡提供的一個優勢是我們可以在事務中執行repair_allow_data_loss，但實際上並不送出它，並衡量您獲得的數據失去量和損壞的數據庫。然後，您實際上可以進一步決定。
我引用了BOL 文件中關於 repair_allow_data_loss的警告部分
REPAIR_ALLOW_DATA_LOSS 選項是 SQL Server 支持的功能。但是，它可能並不總是使數據庫達到物理一致狀態的最佳選擇。如果成功，REPAIR_ALLOW_DATA_LOSS 選項可能會導致一些數據失去。事實上，與使用者從上次已知的良好備份恢復數據庫相比，它可能會導致更多的數據失去。Microsoft 始終建議使用者從上次已知的良好備份還原作為從 DBCC CHECKDB 報告的錯誤中恢復的主要方法。REPAIR_ALLOW_DATA_LOSS 選項不是從已知良好備份恢復的替代方法。這是一個緊急的“最後手段”選項，建議僅在無法從備份恢復時使用。
某些只能使用 REPAIR_ALLOW_DATA_LOSS 選項修復的錯誤可能涉及取消分配一行、一頁或一系列頁以清除錯誤。使用者無法再訪問或恢復任何解除分配的數據，並且無法確定解除分配數據的確切內容。因此，在解除分配任何行或頁面後，引用完整性可能不准確，因為在此修復操作中未檢查或維護外鍵約束。使用 REPAIR_ALLOW_DATA_LOSS 選項後，使用者必須檢查其數據庫的引用完整性（使用 DBCC CHECKCONSTRAINTS）。
在執行修復之前，請創建屬於該數據庫的文件的物理副本。這包括主要數據文件 (.mdf)、任何輔助數據文件 (.ndf)、所有事務日誌文件 (.ldf) 以及構成數據庫的其他容器，包括全文目錄、文件流文件夾、記憶體優化數據等.
在執行修復之前，請考慮將數據庫的狀態更改為 EMERGENCY 模式並嘗試從關鍵表中提取盡可能多的資訊並保存該數據。