1    前言

本文的步驟基于以下條件：

1.     SQL Server可以啟動。

2.     數據庫沒有做有效的備份。

3.     當前用戶有Sysadmin權限。

數據庫質疑的原因會有多種多樣，不同的suspect采用的步驟也會有所不同，以下的步驟不能適用所有的情況，但包括了一些基本的步驟。 數據庫suspect是指數據庫內部處于不一致的狀態，很有可能會有數據丟失。 我們推薦您從“好的數據庫備份”恢復。 我們這里所指的“好的數據庫備份”是指：

1.  在做數據庫備份之前，您檢查過DBCC CHECKDB沒有錯誤。

2.  備份之后的數據庫沒有更改，或者更改可以忽略。

在做任何修復操作之前，請務必備份.mdf/.ndf以及.ldf文件。

2   SQL Server 2000修復步驟

如果沒有“好的數據庫備份”，我們不能保證沒有數據丟失。 以下是恢復suspect數據庫 （SQL Server 2000）的一般方法，供您參考。 同時在操作下列步驟之前，您可以備份質疑數據庫的MDF、NDF、LDF文件，以便以下步驟恢復失敗時能夠回滾到原來的狀態。

1.  在查詢分析器中，運行如下命令將數據庫置于緊急模式。

Sp_configure 'allow update', 1

Go

Reconfigure with override

Go

Begin Tran

Update master..sysdatabases set status = 32768 where name ='<DatabaseName>’

Commit Tran

--此處<DatabaseName>需要替代成您出問題的數據庫名字。

--以下同

Go

Select * from sysdatabases

--檢查數據庫狀態是否已經變成 32768

Go

2. 重啟SQL Server服務。

3.  如果第二步中重啟服務，數據庫再次進入suspect模式，請設置數據庫緊急模式，使用BCP方式導出數據。

否則在查詢分析器中，重新連接到SQL Server，運行如下命令重建日志。

特別注意： dbcc rebuild_log是內部命令，請您閱讀附件中的DBCC Rebuild Run Command.doc。 只有當您同意了附件中的內容，才可以運行此命令。

dbcc rebuild_log('<DatabaseName>’,'<The file name and the path of the log file>')

--此處<The file name and the path of the log file>是新的日志文件的物理文件的絕對地址。

go

如果rebuild_log失敗，請運行如下命令，

Use <DatabaseName>

Go

如果數據庫在emergency 方式能夠進入緊急模式，直接使用BCP方式導出數據，沒有其他方式來恢復數據庫。

如果不能進入，則沒有其他方式恢復數據庫

如果數據庫在Rebuild_log之后恢復正常，進入第四步。

4.  關掉查詢分析器，再次打開查詢分析器，運行如下語句，查詢出問題的數據庫的DBID

Select * from master.dbo.sysdatabases

Go

5.  再運行如下命令，檢查是否有人在使用當前出問題的數據庫，如果有的話，請將他們退出。

Select * from master.dbo.sysprocesses

Go

6.  然后運行如下命令，將數據庫置于單用戶使用模式。如果設置不生效，可以嘗試使用企業管理器->數據庫屬性-> 選項來直接設置．

exec sp_dboption N'<DatabaseName>', N'single', N'true'

7.  在查詢分析器中，運行如下命令，檢查數據庫是否有損壞。

dbcc checkdb(‘<DatabaseName>')

go

8.  如果您運行上述命令發現數據庫有錯誤。 此時我們需要根據錯誤來處理。 接下去有兩個方向。

方向一：

使用Repair_Allow_Data_Loss選項修復數據庫。

優點： 可能可以恢復盡量多的數據

缺點：

a)  不一定能夠將全部錯誤修復，還有可能越修越多。同時，需要大量時間，需要經過多次執行修復命令．十幾次，甚至數十次．修復時間不能預估．

b)  就算我們將所有錯誤修復，我們也不能保證數據在應用程序邏輯這一層次上的數據正確性，您需要找您的應用程序提供商來檢查數據在程序邏輯層次是否正確。

dbcc checkdb ('<DB_name>', REPAIR_ALLOW_DATA_LOSS) go

--此命令可能需要運行多次，才能完全修復。

方向二：

通過BCP，DTS，select into等方式將好的表，或者表中好的數據導出來。建議使用BCP的方法，這樣可以最大限度的回復數據．BCP會停在出錯的紀錄上，但是前面的數據就能成功導出．使用DTS或Select into的話, 我們很難判斷最大限度能導出的記錄數．

優點：導出來的數據保證在應用程序邏輯這一層次的正確性

缺點：不會修復數據庫中存在的錯誤，丟失的數據量會比較大，取決于第7步的運行結果。

9.  數據庫完全恢復正常之后，將數據庫置于正常狀態，并將單用戶模式改成多用戶模式。(16或者0)

begin tran

update sysdatabases set status = 8 where name = 'db_name'

commit tran

sp_configure 'allow', 0

go

reconfigure with override

exec sp_dboption N'<DatabaseName>', N'single', N'false'

go

另外，上述步驟之前或者之中，可能會有數據庫在企業管理器中看不到，并且無法attach的狀況。 通常可以建同名數據庫（注意：物理文件名也要一致），停止SQL Server，覆蓋文件，重啟SQLServer的方式來解決。

3   SQL Server 2005/2008/2008R2修復步驟

方法一

alter database <DatabaseName>set emergency

go

alter database <DatabaseName>set single_user with rollback immediate

go

use <DatabaseName>

go

dbcc checkdb

go

use master

go

alter database <DatabaseName>Rebuild Log on

(name=<DatabaseName>_log,filename='c:\sql\logs\<DatabaseName>_log.LDF')

go

select * from sys.databases

go

dbcc checkdb('<DatabaseName>', repair_allow_data_loss)

go

sp_dboption '<DatabaseName>','single user','false'

方法二

alter database <DatabaseName> set emergency

go

alter database <DatabaseName> set single_user with rollback immediate

go

use master

go

alter database <DatabaseName> Rebuild Log on

(name=<DatabaseName>_log,filename='c:\sql\logs\<DatabaseName>_log.LDF')

go

use <DatabaseName>

go

dbcc checkdb

go

--此時checkdb有錯誤才需要做步驟d)

d) 此時數據庫應處于emergency狀態，創建一個新數據庫，通過bcp/bulk insert/DTS/SSIS方式將數據導出到新的數據庫.

請注意，這種情況下索引，存儲過程，視圖等，都需要手工導出來。

4             導數據總結

1. 創建一個空的數據庫。

2. 使用腳本禁用所有外鍵約束。

       Use <NewDatabase>

GO

DECLARE @disable BIT

set @disable= 1

DECLARE

    @sql VARCHAR(500),

    @tableName VARCHAR(128),

    @foreignKeyName VARCHAR(128)

-- A list of all of the Foreign Keys and the table names

DECLARE foreignKeyCursor CURSOR

    FOR

SELECT

        ref.constraint_name AS FK_Name,

        fk.table_name AS FK_Table

      FROM

        INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS ref

        INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS fk ON ref.constraint_name =fk.constraint_name

      ORDER BY

        fk.table_name,

        ref.constraint_name

OPEN foreignKeyCursor

FETCH NEXT FROM foreignKeyCursor INTO @foreignKeyName, @tableName

WHILE ( @@FETCH_STATUS = 0 )

    BEGIN

     IF @disable = 1

        SET @sql = 'ALTER TABLE [' + @tableName + '] NOCHECK CONSTRAINT [' +@foreignKeyName +