sql server數據庫的檢測及修復方法

隨著K/3產品的推廣，要求客戶服務人員對SQL SERVER數據庫的了解也進一步提高。在K/3的使用過程中，數據庫文件被頻繁地使用，由于某些原因，數據庫有可能被損壞，本文將針對這種情況的數據庫 檢測及修復方法做一簡單講解。希望各位在實際工作過程中有新的發現時，及時給我們提供信息，以便做進一步的更新。

1. 數據文件修復

1.1 SQL SERVER數據庫的檢測

SQL SERVER提供了數據庫檢測的命令，可用DBCC CHECKDB對數據庫中各個對象的分配及結構的正確性進行檢測，并可通過一參數控制，將所有的錯誤信息顯示出來。其語法如下：

DBCCCHECKDB

('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問題數據庫的修復

經過數據庫檢測后，可針對出現的問題采取相應的措施進行處理。如通過檢測后，發現對象的物理存放存在問題，可用DBCCCHECKALLOC來進行修復：

DBCCCHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS |NO_INFOMSGS}]

若是非系統對象的索引出錯，則可用DBCC DBREINDEX進行修復：

DBCCDBREINDEX ( [ '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 ServerService Manager。對Master數據庫將系統表設置為可更改狀態

UseMaster

Go

sp_configure'allow updates', 1

reconfigurewith override

Go

將數據庫設為緊急狀態：

updatesysdatabases set status = 32768 where database '

停止并重新啟動SQL Server Service Manager，并重建Log文件：

DBCCTRACEON (3604)

DBCCREBUILD_LOG(' test ','test _log_ldf')

將數據庫設置為單用戶模式，然后進行檢測：

sp_dboption' test ', 'single user', 'true'

DBCCCHECKDB(' test ')

Go

此數據庫執行CHECKDB的過程中發現一些表的索引被破壞，于是針對具體的表進行重建索引的操作：

DBCCDBREINDEX（表名）

如執行以上操作仍然不能解決，若索引破壞的表是臨時表或不是關鍵表，則可從新建賬套中引入，若是主表，則可能通過近期的備份來（部份）恢復。若沒有一個備份，則無法修復。

1.3 SQL Server數據庫為什么易損壞呢？

以下是微軟提供的一些可能引起數據庫損壞的原因及一些預防措施：

操作問題，包括冷起動機器、熱拔硬盤、刪除一些數據庫文件；

硬件問題，包括磁盤控制器的問題；

操作系統問題，包括與系統相關的一些致命錯誤。

預防措施：

1、定期/不定期執行CHKDSK(不帶參數)，以檢測硬盤物理結構并修復一些CHKDSK報告的問題；

2、常備份數據。

1.5 應用數據庫修復舉例

declare@databasename varchar(255)

set@databasename='AIS20021224170730'------一定要手工輸入

--執行一般性修復還存在問題時,進行允許數據丟失的修復

--許數據丟失的修復要求在單用戶下進行,此時請退出中間層,客戶端,sql的其他模塊

--所有功能退出,在查詢分析器master里設置數據庫為單用戶

execsp_dboption @databasename, N'single', N'true'

--在查詢分析器master里,進行修復數據庫

dbcccheckdb(@databasename,REPAIR_ALLOW_DATA_LOSS)

dbcccheckdb(@databasename,REPAIR_REBUILD)

--還原數據庫狀態

execsp_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 服務,然后運行如下命令:

UseMaster

Go

sp_configure'allow updates', 1

reconfigurewith override

Go

begintran

updatesysdatabases set status = 32768 where db_name'

-- Verifyone row is updated before committing

committran

2.5步驟5:

停止SQL然后重新啟動SQL Server 服務,然后運行如下命令:

DBCCTRACEON (3604)

DBCCREBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')

Go

2.6步驟6:

停止SQL然后重新啟動SQL Server 服務,然后運行:

usemaster

update sysdatabasesset status = 8 where

Go

sp_configure'allow updates', 0

reconfigurewith override

Go

2.7步驟7:

運行dbcc checkdb(db_name)檢查數據庫的完整性.

3 數據庫質疑的一般處理

1、執行如下SQL（打開修改系統表的開關）：

EXECsp_configure 'allow updates', 1

RECONFIGUREWITH OVERRIDE

2、修改數據庫Master中的表：sysdatabases

將 status字段數值更改為4

3、再執行如下SQL：

EXECsp_configure 'allow updates', 0

RECONFIGUREWITH OVERRIDE。