/*
重要：如果有備份，最好是從備份恢復數據。
由於帶有 REPAIR 選項的 DBCC CHECKDB 已完全記錄並可恢復，因此 Microsoft 始終建議用戶在事務中使用帶有 REPAIR 選項的 DBCC CHECKDB（在運行命令之前執行 BEGIN TRANSACTION），這樣用戶可確認其是否願意接受操作的結果。 然後用戶可執行 COMMIT TRANSACTION 來提交修復操作完成的所有工作。 如果用戶不想接受操作的結果，可執行 ROLLBACK TRANSACTION 以撤消修復操作的影響。
若要修復錯誤，建議您通過備份進行還原。 修復操作不會考慮表本身或表之間可能存在的任何約束。 如果指定的表與一個或多個約束有關，建議在修復操作後運行 DBCC CHECKCONSTRAINTS。 如果必須使用 REPAIR，則運行不帶有修復選項的 DBCC CHECKDB 來查找要使用的修復級別。 如果要使用 REPAIR_ALLOW_DATA_LOSS 級別，建議在運行帶有此選項的 DBCC CHECKDB 之前備份數據庫。
*/
--最好是禁用網絡。因爲單用戶模式下可能會有其他客戶端爭搶。
--修改數據庫爲緊急模式
ALTER DATABASE basename SET EMERGENCY
--使數據庫變爲單用戶模式
ALTER DATABASE basename SET SINGLE_USER
/*
指定 DBCC CHECKDB 修復發現的錯誤。僅將 REPAIR 選項作爲最後手段使用。 指定的數據庫必須處於單用戶模式，才能使用以下修復選項之一。
REPAIR_ALLOW_DATA_LOSS
嘗試修復報告的所有錯誤。 這些修復可能會導致一些數據丟失。
警告：REPAIR_ALLOW_DATA_LOSS 選項是受支持的功能，但是，它可能並非總是使數據庫處於物理上一致的狀態的最佳選項。 如果成功，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 模式，並嘗試從關鍵表中提取儘可能多的信息並保存這些數據。
*/
DBCC CheckDB ( basename , REPAIR_ALLOW_DATA_LOSS)
--使數據庫變回爲多用戶模式
ALTER DATABASE basename SET MULTI_USER
-- 使用SQL語句查看當前連接的用戶
select spid,db_name(dbid) as DBname,login_time ,last_batch ,status ,hostname ,program_name ,loginame
from sys.sysprocesses
where spid >50
order by last_batch desc
--如果數據庫連接被其他用戶佔用，請先切斷。
kill 55