『壹』 資料庫置疑怎樣解決
企業管理器--右鍵suspect的資料庫--所有任務--分離資料庫
然後備份你的suspect資料庫的文件,再按下面的步驟處理:
1.新建一個同名的資料庫
2.再停掉sql server
3.用suspect資料庫的文件覆蓋掉這個新建的同名資料庫
4.再重啟sql server
5.此時打開企業管理器時新建的同名資料庫會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='his222'
Go
sp_dboption 'test', 'single user', 'true'
Go
DBCC CHECKDB('test')
Go
update sysdatabases set status =28 where name='test'
Go
sp_configure 'allow updates', 0 reconfigure with override
Go
sp_dboption 'test', 'single user', 'false'
Go
6.完成後一般就可以訪問資料庫中的數據了,這時,資料庫本身一般還要問題,解決辦法是,利用
資料庫的腳本創建一個新的資料庫,並將數據導進去就行了.
如果這樣改不加資料庫狀態,你就把資料庫導成一個新庫來代替舊庫吧
企業管理器--右鍵你的資料庫--所有任務--導出數據
--目標標資料庫選擇新建
--選擇"在兩個sql資料庫之間復制對象和數據"
--把"包含擴展屬性"選上,其他的根據需要選擇
--最後完成
『貳』 sql資料庫質疑的原因及解決辦法
sql資料庫質疑是設置錯誤造成的，解決方法為：
1、通過DBCC CHECKCB('DBName') 來檢測資料庫異常的原因，如果可以檢測到資料庫的異常，其中紅色部分即時數據目前存在的問題，我們也在檢測結果最後看到數據的總體的錯誤情況的匯總。
『叄』 sql2000資料庫數據文件損壞造成的置疑能修復嗎
可以修復，從故障解析，資料庫損壞分為
邏輯層
損壞和
物理層
損壞。
1，邏輯損壞是指，文件本身完整，系統表在
邏輯結構
上混亂造成的錯誤。
2，物理損壞是指，文件由於不完整，導致置疑等故障
資料庫損壞，由斷電，非法關機，系統重啟，文件被誤刪除，誤GHOST自己恢復出來的文件附加失敗，陣列崩潰等原因造成的。
邏輯層修復方法，網上有很多DBCC修復命令，可以區嘗試下、
物理層還是找專業人員吧！
『肆』 如何修復 SQL 資料庫置疑
修復sql2000資料庫置疑
在實際的操作中由於突然斷電或者突然斷網造成資料庫置疑（在企業管理器中資料庫後面出現置疑兩個字），下面我們通過以下方法來進行修復置疑的資料庫。
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
『伍』 sql資料庫置疑怎麼處理
修復方法
1
打開SQL企業管理器
按序打開 ,開始--所有程序（或程序）--Microsoft SQL Server--企業管理器
打開後按序點+號展開直到資料庫
『陸』 msdb資料庫置疑如何恢復
MSDB資料庫解決過程難點：由於MSDB資料庫不能刪除，將其文件拷出來，再次附加資料庫，但新的附加資料庫不能叫MSDB，也就是不能同名，遇到了困難。 1：先停止整個資料庫，將該資料庫的文件msdbdata.mdf和msdblog.ldf拷貝粘貼出來到另一個目錄下。 2：將以上的文件再拷貝到另一個目錄下，也就是說復制兩次。 3：選擇 資料庫右擊滑鼠 --》所有任務--》附加資料庫 將復制出的一個備份文件附加上去，其中，資料庫名稱叫MSDB1，用戶是SA或ADMINISTRATOR。 4：將MSDB1資料庫備份，備份成一個文件，當時我的叫MSDB。BAK。 5：選擇置疑的資料庫MSDB，選擇恢復資料庫，將剛才備份出來的資料庫強行恢復到MSDB。 6：問題解決，MSDB庫又能正常使用。
『柒』 資料庫出現置疑了怎麼恢復
備份數據文件,然後按下面的步驟處理:
1.新建一個同名的資料庫(數據文件與原來的要一致)
2.再停掉sql server(注意不要分離資料庫)
3.用原資料庫的數據文件覆蓋掉這個新建的資料庫
4.再重啟sql server
5.此時打開企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)
6.完成後一般就可以訪問資料庫中的數據了,這時,資料庫本身一般還要問題,解決辦法是,利用
資料庫的腳本創建一個新的資料庫,並將數據導進去就行了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 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 reconfigure with override
Go
sp_dboption '置疑的資料庫名', 'single user', 'false
假設資料庫為TEST：
按以下步驟執行
A．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
B．設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
C．下面執行真正的恢復操作，重建資料庫日誌文件
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使用」。此時可以訪問資料庫裡面的用戶表了。
D．驗證資料庫一致性（可省略）
dbcc checkdb('test')
一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
E．設置資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
F．最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
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','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
『捌』 如何解決SQL Server資料庫置疑問題
您好，是這樣的：
1.首先確認已經備份了.mdf和.ldf文件。
2. 在SQL Server中新建一個同名的資料庫，然後停止SQL Server服務。
3. 用原有的.mdf和.ldf文件覆蓋新建資料庫對應的.mdf和.ldf文件。
4. 重新啟動SQL Server服務，這是應該會看到這個資料庫處於置疑（Suspect）狀態。
5. 在SQL查詢分析器中執行以下命令，以允許更新系統表：use mastergosp_configure "allow updates",1reconfigurewithoverridego。
6. 將這個資料庫置為緊急模式：update sysdatabases set status = 32768 where name="db_name"go。
7. 使用DBCC CHECKDB命令檢查資料庫中的錯誤：DBCC CHECKDB("db_name")GO。
8. 如果DBCC CHECKDB命令失敗，請轉至第10步，否則先將資料庫置為單用戶模式，再嘗試對其進行修復：sp_dboption "db_name","single
user","true"DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)GO
如果在執行DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令時提示說資料庫未處於單用戶模式狀態的話，則重新啟動SQLServer服務，然後繼續嘗試。
9. 如果DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令失敗，請轉至第10步，否則若成功修復了資料庫中的錯誤：
重新執行DBCC CHECKDB("db_name")命令，確認資料庫中已沒有錯誤存在。
清除資料庫的置疑狀態：sp_resetstatus "db_name"
清除資料庫的單用戶模式狀態：sp_dboption "db_name","single user","false"
重新啟動SQL Server服務，如果一切正常的話，則資料庫已經成功恢復。
10.如果以上步驟都不能解決問題的話，請參考附件中的文檔嘗試通過重建事務日誌來恢復資料庫中的數據。如果您只有MDF文件，問題就更加復雜一些，我們需要直接重建事務日誌了:
1. 在SQL Server中新建一個同名的資料庫，然後停止SQL Server服務。
2. 用原有的ldf文件覆蓋新建資料庫對應的.mdf文件，將其日誌文件（.ldf）刪除。
3. 啟動SQL Server服務，並將資料庫置為緊急模式（同上: 步驟5和步驟6）。
4. 停止並重新啟動SQL Server服務。
5. 執行以下命令重建資料庫日誌文件：(下面是個示例，您要用您實際的資料庫名)
DBCC REBUILD_LOG（"cas_db", "D:\cas_db\cas_db_Log.LDF"）
6. 重新將該資料庫置為單用戶模式。
7. 再次嘗試使用DBCC CHECKTABLE或DBCC CHECKDB命令檢查並修復資料庫中。
『玖』 sql資料庫置疑，錯誤代碼926，請問要如何修復
請輸入你的答案...
資料庫926錯誤解決方案在做任何操作前首先備份資料庫的數據文件和日誌文件！以及最新的備份文件！第一種解決方法：先刪除報錯資料庫，再新建一同名資料庫，然後暫停Service
manager（及sql
server
服務）
，刪除庫文件和日誌文件再啟動Service
manager
，使用單數據文件恢復資料庫命令恢復資料庫。例：打開sql
server/tools/sql
server
query
analyzer
執行下面操作
EXEC
sp_attach_single_file_db
@dbname
=
'pubs',
@physname
=
'c:\mssql7\data\pubs.mdf'
說明：『pubs』為要恢復的資料庫名稱，『c:\mssql7\data\pubs.mdf』為要恢復的資料庫的庫文件的具體路徑和文件名稱。再重新啟動一下service
manager
，看能否正常打開處理後的資料庫；如果不可以再使用第二種方案。第二種解決方法：打開sql
server/tools/sql
server
query
analyzer
執行下面操作
USE
MASTER
GO
sp_configure
'allow
update',1
RECONFIGURE
WITH
OVERRIDE
GO
UPDATE
sysdatabases
set
status
=
32768
WHERE
name
=
'db_pos363'
GO
sp_configure
'allow
update',0
RECONFIGURE
WITH
OVERRIDE
GO
說明：'db_pos363'是要修復的資料庫名稱。執行完畢再重啟一下Service
manager打開資料庫看是否處於緊急狀態！再從另一裝有sql
2000的機器上連接報錯的資料庫，然後再在sql
2000的機器上新建一資料庫，再使用sql
2000自帶的資料庫導入導出功能（在新建的資料庫上單擊右鍵/所有任務/數據導入、數據導出）從報錯資料庫導入數據到新建的資料庫中！在導入選項中注意以下幾項：
1，
導入方式選擇分『從源資料庫復製表和視圖』以及『從sql
server資料庫間復制對象和數據』。當選擇從源資料庫復製表和視圖時一定要選擇全部表！
2，
當選擇『從sql
server資料庫間復制對象和數據』時，在『導入導出向導』對話框中去除『使用默認選項』的選中標志；再在打開『選項』對話框，去除以下三項的選中標志。A,復制數據用戶和資料庫角色；B，復制sql
server
登陸；C，復制對象及許可權。
3，
在使用『從sql
server資料庫間復制對象和數據』時，有時會出現單張表導入失敗，這時有時會在導入結束時提示那幾張表導入失敗有時不提示，如果提示，就再使用『從源資料庫復製表和視圖』並選中導入失敗的表重新導入一遍；如果不提示就只能在一張張表打開查看了，發現空表後再使用『從源資料庫復製表和視圖』導入需要導入的表！導入成功後再刪除sql
server
7.0機器上處於緊急狀態的資料庫，再新建一個同名資料庫，建好後再使用sql
2000的資料庫導出功能導出到此資料庫中，在導出過程中同樣要注意導入時的注意事項！