1、停止資料庫伺服器，將資料庫MDF檔案和LDF檔案複製備份一份
2、啟動資料庫伺服器，刪除置疑的資料庫
3、僅用備份的資料庫MDF檔案附加資料庫，sp_attach_db或者sp_attach_single_file_db可以附加資料庫，出現類似下面的提示資訊：
裝置啟用錯誤。物理檔案名稱 'C:/Program Files/Microsoft SQL Server/MSSQL/data/myDb_Log.LDF' 可能有誤。
已建立名為 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.LDF' 的新記錄檔。
這個表明資料庫附加成功，問題解決了，如果成功則要恭喜你了，反正我是符加不成功，提示類似下面的錯誤資訊
未能開啟新資料庫 'myDb'。CREATE DATABASE 將終止。
裝置啟用錯誤。物理檔案名稱 'e:/www/myDb_log.LDF' 可能有誤。
此時我用了以下方法解決（參考了網上的方法）。
A．我們SQL SERVER企業管理器建立立一個供恢複使用的同名資料庫(注意：要跟問題資料庫同名，本例中為myDb)。
B．停掉資料庫伺服器。
C．將剛才產生的資料庫的記錄檔myDb_log.ldf刪除（本例中的示列資料庫名，實際使用您自己的資料庫名稱），用剛才備份的資料庫mdf檔案覆蓋新產生的資料庫資料檔案myDb_data.mdf。
D．啟動資料庫伺服器。此時會看到資料庫myDb的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
E．設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右--鍵，選擇“屬性”，在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go F．設定myDb為緊急修複模式
在查詢管理器裡設定如下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('myDb')此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀/置疑/離線/緊急模式”可以看到資料庫裡面的表，但是僅僅有系統資料表
G．下面執行真正的恢複操作，重建資料庫記錄檔
dbcc rebuild_log('myDb','C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.ldf')警告: 資料庫 'myDb' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重設資料庫選項，並且可能需要刪除多餘的記錄檔。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。
此時開啟在SQL Server Enterprise Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。
H．驗證資料庫一致性（可省略）
dbcc checkdb('myDb')一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'myDb' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。
I．設定資料庫為正常狀態
sp_dboption 'myDb','dbo use only','false' J．最後一步，我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢複，也可以使用如下陳述式完成
sp_configure 'allow updates',0
go
reconfigure with override
go
到此資料庫置疑問題解決。
資料二
MS SQL SERVER資料庫置疑後恢複步驟
--SQL SERVER資料庫置疑後恢複步驟
--1． 恢複步驟：
--a.將smlog_log.ldf檔案備份到其它目錄下；
--b.將來源目錄下的smlog_log.ldf檔案改名為smlog_log_bak.ldf；
--c.執行以下語句修改資料庫的狀態：
use Master
go
update sysdatabases set status=32768 where name='資料庫名稱' --修改狀態,設為緊急狀態
go
shutdown with nowait --停止資料庫伺服器
go
--d.退出SQL並在(COMMAND)命令列模式中通過下面的代碼重新啟動SQL：
sqlservr -c -T3608 -T4022 --安全模式啟動SQL SERVER
--e.在查詢分析器中執行以下語句來查看剛剛修改過狀態的資料庫狀態：
select Name,Status from sysdatabases where Name='資料庫名稱'
--f.執行以下代碼建立記錄檔：
dbcc traceon(3604)--跟蹤
dbcc rebuild_log('資料庫名稱','記錄檔全路徑') --檔案名稱要有全路徑和副檔名
--dbcc rebuild_log('prs_msc','d:/mscsql/mssql/data/prs_msc_log.ldf
--g.將資料庫置回正常狀態：
update sysdatabases set status=0 where name='資料庫名稱'
--h.重新啟動資料庫後執行以下語句檢查資料庫：
DBCC CHECKDB --如果執行完有錯誤用以下語句修複
--i.要修複資料庫必需將資料庫改為單一使用者模式：
Exce sp_dboption '資料庫名稱','single user','true'---('false'恢複多使用者)
--j.執行以下語句修複資料庫：
DBCC CHECKDB('資料庫名稱',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS：是比較進階的修複方式
REPAIR_FAST：是簡單快速的修複方式
/*
處理狀態就為"置疑"的數據庫
備份資料檔案,然後按下面的步驟處理:
1.建立一個同名的資料庫(資料檔案與原來的要一致)
2.再停掉sql server(注意不要分離資料庫)
3.用原資料庫的資料檔案覆蓋掉這個建立的資料庫
4.再重啟sql server
5.此時開啟企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)
6.完成後一般就可以訪問資料庫中的資料了,這時,資料庫本身一般還要問題,解決辦法是,利用資料庫的指令碼建立一個新的資料庫,並將資料導進去就行了.
*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的資料庫名'
Go
sp_dboption '置疑的資料庫名','single user','true'
Go
DBCC CHECKDB('置疑的資料庫名')
Go
update sysdatabases set status=28 where name='置疑的資料庫名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的資料庫名', 'single user','false'
Go
/*
只有mdf檔案的恢複技術
由於種種原因，我們如果當時僅僅備份了mdf檔案，那麼恢複起來就是一件很麻煩的事情了。
如果您的mdf檔案是當前資料庫產生的，那麼很僥倖，也許你使用sp_attach_db或者sp_attach_single_file_db可以恢複資料庫，但是會出現類似下面的提示資訊
裝置啟用錯誤。物理檔案名稱 'C:/Program Files/Microsoft SQL Server/MSSQL/data/test_Log.LDF' 可能有誤。
已建立名為 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.LDF' 的新記錄檔。
但是，如果您的資料庫檔案是從其他電腦上複製過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤資訊
伺服器: 訊息 1813，層級 16，狀態 2，行 1
未能開啟新資料庫 'test'。CREATE DATABASE 將終止。
裝置啟用錯誤。物理檔案名稱 'd:/test_log.LDF' 可能有誤。
怎麼辦呢。別著急，下面我們舉例說明恢複辦法。
*/
--A．我們使用預設建立一個供恢複使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
--B．停掉資料庫伺服器。
--C．將剛才產生的資料庫的記錄檔test_log.ldf刪除，用要恢複的資料庫mdf檔案覆蓋剛才產生的資料庫資料檔案test_data.mdf。
--D．啟動資料庫伺服器。此時會看到資料庫test的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
--E．設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右--鍵，選擇“屬性”，在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--F．設定test為緊急修複模式
--在查詢管理器裡設定如下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀/置疑/離線/緊急模式”可以看到資料庫裡面的表，但是僅僅有系統資料表
--G．下面執行真正的恢複操作，重建資料庫記錄檔
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')
/*
執行過程中，如果遇到下列提示資訊：
伺服器: 訊息 5030，層級 16，狀態 1，行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。
說明您的其他程式正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager開啟了test庫的系統資料表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重設資料庫選項，並且可能需要刪除多餘的記錄檔。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。
此時開啟在SQL Server Enterprise Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。
*/
--H．驗證資料庫一致性（可省略）
dbcc checkdb('test')
/*一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。*/
--I．設定資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
--如果沒有出錯，那麼恭喜，現在就可以正常的使用恢複後的資料庫啦。
--J．最後一步，我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢複，也可以使用如下陳述式完成
sp_configure 'allow updates',0
go
reconfigure with override
go
--記錄檔出現問題（丟失或檔案格式非法），怎麼使資料庫恢複正常
--如果用sp_attach_single_file 'TEST','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.mdf'失敗則需要用下列步驟完成
--1.將置疑的資料庫分離，將mdf檔案移走或改名。
sp_detach_db 'TEST'
--2.重新在原來目錄下建立同名的資料庫TEST
--3.停掉SQL Service,將先前的mdf檔案拷貝回來覆蓋(或改名),刪除原來的log檔案(或改名)
--4.啟動SQL Service(否則下面的語句沒辦法運行)
--5.將資料庫設成緊急模式(status=32768)
sp_configure 'allow updates',1
reconfigure with override
update sysdatabases set status=32768 where name='TEST'
--重建立立記錄檔
DBCC traceon(3604)
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')
Go
--6.重新啟動SQL Service
--7.將資料庫設定成單一使用者模式(下面三個語句均可)
--sp_dboption 'TEST','single user','true'
update sysdatabases set status=4096 where name='TEST'
--alter database TEST set Single_user
--8.檢查資料庫的完整性和一致性,OK了就可以用了
DBCC CheckDB(TEST)
--9.將資料的存取權限設定成多使用者模式
sp_dboption 'TEST','single user','false'
--或alter database TEST set multi_user
--10.關閉進階選項
sp_configure 'allow updates',0
reconfigure with override
--SQL SERVER資料庫置疑後恢複步驟
--1． 恢複步驟：
--a.將smlog_log.ldf檔案備份到其它目錄下；
--b.將來源目錄下的smlog_log.ldf檔案改名為smlog_log_bak.ldf；
--c.執行以下語句修改資料庫的狀態：
use Master
go
update sysdatabases set status=32768 where name='資料庫名稱' --修改狀態,設為緊急狀態
go
shutdown with nowait --停止資料庫伺服器
go
--d.退出SQL並在(COMMAND)命令列模式中通過下面的代碼重新啟動SQL：
sqlservr -c -T3608 -T4022 --安全模式啟動SQL SERVER
--e.在查詢分析器中執行以下語句來查看剛剛修改過狀態的資料庫狀態：
select Name,Status from sysdatabases where Name='資料庫名稱'
--f.執行以下代碼建立記錄檔：
dbcc traceon(3604)--跟蹤
dbcc rebuild_log('資料庫名稱','記錄檔全路徑') --檔案名稱要有全路徑和副檔名
--dbcc rebuild_log('prs_msc','dmscsqlmssqldataprs_msc_log.ldf
--g.將資料庫置回正常狀態：
update sysdatabases set status=0 where name='資料庫名稱'
--h.重新啟動資料庫後執行以下語句檢查資料庫：
DBCC CHECKDB --如果執行完有錯誤用以下語句修複
--i.要修複資料庫必需將資料庫改為單一使用者模式：
Exce sp_dboption '資料庫名稱','single user','true'---('false'恢複多使用者)
--j.執行以下語句修複資料庫：
DBCC CHECKDB('資料庫名稱',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS：是比較進階的修複方式
REPAIR_FAST：是簡單快速的修複方式
處理狀態就為置疑的數據庫
備份資料檔案,然後按下面的步驟處理
1.建立一個同名的資料庫(資料檔案與原來的要一致)
2.再停掉sql server(注意不要分離資料庫)
3.用原資料庫的資料檔案覆蓋掉這個建立的資料庫
4.再重啟sql server
5.此時開啟企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)
6.完成後一般就可以訪問資料庫中的資料了,這時,資料庫本身一般還要問題,解決辦法是,利用資料庫的指令碼建立一個新的資料庫,並將資料導進去就行了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的資料庫名'
Go
sp_dboption '置疑的資料庫名','single user','true'
Go
DBCC CHECKDB('置疑的資料庫名')
Go
update sysdatabases set status=28 where name='置疑的資料庫名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的資料庫名', 'single user','false'
Go
--A．我們使用預設建立一個供恢複使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
--B．停掉資料庫伺服器。
--C．將剛才產生的資料庫的記錄檔test_log.ldf刪除，用要恢複的資料庫mdf檔案覆蓋剛才產生的資料庫資料檔案test_data.mdf。
--D．啟動資料庫伺服器。此時會看到資料庫test的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
--E．設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右--鍵，選擇“屬性”，在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--F．設定test為緊急修複模式
--在查詢管理器裡設定如下命令：
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀置疑離線緊急模式”可以看到資料庫裡面的表，但是僅僅有系統資料表
--G．下面執行真正的恢複操作，重建資料庫記錄檔
dbcc rebuild_log('test','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')
SQL Server交易記錄可能會被填滿，這會阻止之後的資料庫操作，包括UPDATE， DELETE， INSERT 和CHECKPOINT。
交易記錄填滿會導致1105錯誤:
Can't allocate space for object syslogs in database dbname because
the logsegment is full。 If you ran out of space in syslogs， dump
the transaction log。 Otherwise use ALTER DATABASE or
sp_extendsegment to increase the size of the segment。
GO
ALTER DATABASE DB_NAME SET RECOVERY SIMPLE
b.如果你的復原模式是全部,你一定要配置日誌欄位收縮:
USE MASTER
GO
sp_dboption 'databasename','trunc. log on chkpt.',true
sp_dboption 'databasename','autoshrink',true
c.通過每日備份將日誌收縮:
BACKUP DATABASE DATABASE_NAME TO BACKUP_DEVICES
BACKUP LOG DATABASE_NAME TO LOG_DEVICES
OR
BACKUP LOG DATABASE_NAME with truncate_only
**檢查日誌的容量:DBCC SQLPERF (LOGSPACE) 這時日誌並沒有收縮!
d.每天在備份資料庫完成之後,重新啟動MS SQLSERVER SERVICE.
USE DATABASE_NAME
go
DBCC SHRINKFILE(2,truncateonly)
**檢查日誌的容量:DBCC SQLPERF (LOGSPACE) 這時日誌已經收縮!
e.手動快速收縮日誌:
/ *run below script,you will shrink you database log files
immediately, in my experience,you need to run the script for 3 or
4 minutes before stopping it manually */
use databasename
dbcc shrinkfile(2,notruncate)
dbcc shrinkfile(2,truncateonly)
create table t1(char1 char(4000))
go
declare @i int
select @i=0
while(1=1)
begin
while(@i<100)
begin
INSERT INTO T1 VALUES ('A')
SELECT @I=@I+1
END
TRUNCATE table T1
BACKUP LOG youdatabasename with truncate_only
end
GO
