手工修復數據庫
1、快速修復
DBCC CHECKDB ('數據庫名', REPAIR_FAST)
2、重建索引并修復
DBCC CHECKDB ('數據庫名', REPAIR_REBUILD)
3、如果必要允許丟失數據修復
DBCC CHECKDB ('數據庫名'', REPAIR_ALLOW_DATA_LOSS)
如果出現錯誤：未處理修復語句。數據庫需處于單用戶模式下。
可以先啟用單用戶模式，方法如下執行存儲過程：
Use master
go
sp_dboption 數據庫名, single, true
--更改成單用戶
alter database test set single_user with rollback immediate
--還原數據庫為多用戶模式
alter database test set multi_user with rollback immediate
############################################################
############################################################
手工修復數據庫試例
操作步驟:
進入SQL查詢分析器,執行語句:
--檢查數據庫完整性
dbcc checkdb('ams1')
執行結果:
CHECKDB 發現了 0 個分配錯誤和 11 個一致性錯誤（在數據庫 'test' 中）。
repair_allow_data_loss 是最低的修復級別（對于由 DBCC CHECKDB (test ) 發現的錯誤而言）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明數據庫確實有問題,11個錯誤,找到錯誤地方:
對象 'Tb_Archives_File_1' 有 3777 行，這些行位于 172 頁中。
CHECKDB 發現了 0 個分配錯誤和 2 個一致性錯誤（在表 'Tb_Archives_File_1' 中，該表的對象 ID 為 907150277）。
表明 'Tb_Archives_File_1' 表確實有2個錯誤,難怪一查詢就要死機,于是運行語句進行表修復:
--以repair_allow_data_loss級別修復表
dbcc checktable('Tb_Archives_File_1',repair_allow_data_loss)
go
執行結果:
服務器: 消息 7919，級別 16，狀態 3，行 2
未處理修復語句。數據庫需要處于單用戶模式下。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
需要將數據庫改為"單用戶模式",于是再執行:
--更改成單用戶
alter database test set single_user with rollback immediate
go
--已repair_allow_data_loss級別修復表
dbcc checktable('Tb_Archives_File_1',repair_allow_data_loss)
go
--若還有問題，修復索引表
DBCC DBREINDEX('Tb_Archives_File_1')
--再修復表
DBCC CHECKTABLE('Tb_Archives_File_1')
直到返回的結果沒有錯誤!
--查詢是否正常
select * from Tb_Archives_File_1
再查詢那張錯誤表,不報錯,也不死機了,數據也完好無損.....哈哈....
--還原數據庫為多用戶模式
alter database test set multi_user with rollback immediate
MS Sql Server 提供了很多數據庫修復的命令，當數據庫質疑或是有的無法完成讀取時可以嘗試這些修復命令。
1. DBCC CHECKDB
重啟服務器后，在沒有進行任何操作的情況下，在SQL查詢分析器中執行以下SQL進行數據庫的修復，修復數據庫存在的一致性錯誤與分配錯誤。
use master
declare @databasename varchar(255)
set @databasename='需要修復的數據庫實體的名稱'
exec sp_dboption @databasename, N'single', N'true' --將目標數據庫置為單用戶狀態
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--將目標數據庫置為多用戶狀態
然后執行 DBCC CHECKDB('需要修復的數據庫實體的名稱') 檢查數據庫是否仍舊存在錯誤。注意：修復后可能會造成部分數據的丟失。
DBCC CHECKTABLE
如果DBCC CHECKDB 檢查仍舊存在錯誤，可以使用DBCC CHECKTABLE來修復。
use 需要修復的數據庫實體的名稱
declare @dbname varchar(255)
set @dbname='需要修復的數據庫實體的名稱'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修復的數據表的名稱',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修復的數據表的名稱',REPAIR_REBUILD)
------把’ 需要修復的數據表的名稱’更改為執行DBCC CHECKDB時報錯的數據表的名稱
exec sp_dboption @dbname,'single user','false'其他的一些常用的修復命令
DBCC DBREINDEX 重建指定數據庫中表的一個或多個索引
用法：DBCC DBREINDEX (表名,’’) 修復此表所有的索引。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
SQL SERVER數據庫的檢測及修復方法
隨著K/3產品的推廣，要求客戶服務人員對SQL SERVER數據庫的了解也進一步提高。在K/3的使用過程中，數據庫文件被頻繁地使用，由于某些原因，數據庫有可能被損壞，本文將針對這種情況的數據庫檢測及修復方法做一簡單講解。希望各位在實際工作過程中有新的發現時，及時給我們提供信息，以便做進一步的更新。
1.1 SQL SERVER數據庫的檢測
SQL SERVER提供了數據庫檢測的命令，可用DBCC CHECKDB對數據庫中各個對象的分配及結構的正確性進行檢測，并可通過一參數控制，將所有的錯誤信息顯示出來。其語法如下：
DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
}]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
參數說明：
'database_name'代表被檢測的數據庫實體名；
NOINDEX指非系統表的非聚族索引不檢測；
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修復發現的錯誤，其中REPAIR_ALLOW_DATA_LOSS代表，若此錯誤不能修復時，系統將直接刪除相關數據。帶此三個參數的任一個時，數據庫必須處于單用戶模式，可在Enterprise Manager中的數據庫屬性中設置；
ALL_ERRORMSGS代表將檢測到的錯誤信息全部顯示出來，否則，對于每張表最多只顯示200條錯誤信息；
NO_INFOMSGS代表隱藏所有的信息及占用空間的報告。
經過檢測，對于錯誤的對象，將以OBJECT ID的形式報告具體出錯的信息，可根據OBJECT ID到系統表sysobjects中查找到相關的表，即NAME。
1.2 SQL SERVER問題數據庫的修復
經過數據庫檢測后，可針對出現的問題采取相應的措施進行處理。如通過檢測后，發現對象的物理存放存在問題，可用DBCC CHECKALLOC來進行修復：
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系統對象的索引出錯，則可用DBCC DBREINDEX進行修復：
DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]
以上兩種情況，也可直接使用DBCC CHECKDB(‘db_name’,repair_rebuild)來修復。
另外一種情況是在進行檢測時，提示無法建立數據連接，此時表明，數據庫已損壞。對于這種情況，我們可采取如下措施來嘗試修復。
首先，在SQL Enterprise中新建一數據庫（如數據庫名為test）,建好數據庫后，停止SQL Server Service Manager，并將客戶數據庫的MDF文件更名為test _data.mdf(即新建數據庫的主文件名)，然后用更名后的文件覆蓋新建數據庫同名文件，接著，啟動SQL Server Service Manager。對Master數據庫將系統表設置為可更改狀態
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
將數據庫設為緊急狀態：
update sysdatabases set status = 32768 where database '
停止并重新啟動SQL Server Service Manager，并重建Log文件：
DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
將數據庫設置為單用戶模式，然后進行檢測：
sp_dboption ' test ', 'single user', 'true'
DBCC CHECKDB(' test ')
Go
此數據庫執行CHECKDB的過程中發現一些表的索引被破壞，于是針對具體的表進行重建索引的操作：
DBCC DBREINDEX（表名）
如執行以上操作仍然不能解決，若索引破壞的表是臨時表或不是關鍵表，則可從新建賬套中引入，若是主表，則可能通過近期的備份來（部份）恢復。若沒有一個備份，則無法修復。
1.3 SQL Server數據庫為什么易損壞呢？
以下是微軟提供的一些可能引起數據庫損壞的原因及一些預防措施：
操作問題，包括冷起動機器、熱拔硬盤、刪除一些數據庫文件；
硬件問題，包括磁盤控制器的問題；
操作系統問題，包括與系統相關的一些致命錯誤。
1.4 預防措施：
1、定期/不定期執行CHKDSK(不帶參數)，以檢測硬盤物理結構并修復一些CHKDSK報告的問題；
2、常備份數據。
1.5 應用數據庫修復舉例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工輸入
---------執行一般性修復還存在問題時,進行允許數據丟失的修復
---------許數據丟失的修復要求在單用戶下進行,此時請退出中間層,客戶端,sql的其他模塊
---所有功能退出,在查詢分析器master里設置數據庫為單用戶
exec sp_dboption @databasename, N'single', N'true'
-----在查詢分析器master里,進行修復數據庫
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
------還原數據庫狀態
exec sp_dboption @databasename, N'single', N'false'
第2章數據庫日志損壞的修復
請遵照如下步驟來試圖重建數據庫事務日志.
注意: 由于事務日志丟失, 數據庫可能有沒有提交的數據.
注:都要替換成真實的數據庫名字
2.1 步驟1:
創建一個新的數據庫,命名為原來數據庫的名字.
2.2步驟2:
停止SQL Server
2.3步驟3:
把老數據庫的MDF文件替換新數據庫的相應的MDF文件, 并把LDF文件刪除
2.4步驟4:
重新啟動SQL Server 服務,然后運行如下命令:
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
begin tran
update sysdatabases set status = 32768 where db_name'
-- Verify one row is updated before committing
commit tran
2.5步驟5:
停止SQL然后重新啟動SQL Server 服務,然后運行如下命令:
DBCC TRACEON (3604)
DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')
Go
2.6步驟6:
停止SQL然后重新啟動SQL Server 服務,然后運行:
use master
update sysdatabases set status = 8 where
Go
sp_configure 'allow updates', 0
reconfigure with override
Go
2.7步驟7:
運行dbcc checkdb(db_name)檢查數據庫的完整性.
第3章 數據庫質疑的一般處理
1、執行如下SQL（打開修改系統表的開關）：
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
2、修改數據庫Master中的表：sysdatabases
將 status字段數值更改為4
3、再執行如下SQL：
EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE。
