數據庫“置疑”該怎么處理
解決由于sql2000日志文件引起的“置疑”。
日志有錯誤--------重新附加提示日志有錯誤。
日志文件丟失-----丟失了.ldf文件，只有.mdf文件的數據庫重建。
步驟：
一、備份“置疑”數據庫的數據文件，因為日志文件.ldf出錯，可以只備份.mdf文件。
二、打開企業管理器（SQL Server Enterpri Manager），刪除“置疑”數據庫，如果提示刪除錯誤，可以重啟數據庫服務器，然后再試。
三、在企業管理器中，新建同名數據庫（假如數據庫為test），注意建立的數據庫名稱，還有數據文件名要保持和原數據庫一致。
四、停止數據庫服務器。
五、將剛才新建數據庫生成的數據庫的日志文件test_log.ldf刪除，用要恢復的數據庫.mdf文件覆蓋剛才生成的數據庫數據文件test_data.mdf。
六、啟動數據庫服務器。此時會看到數據庫test的狀態為“置疑”。這時候不能對此數據庫進行任何操作。
七、設置數據庫允許直接操作系統表。此操作可以在企業管理器（SQL Server Enterpri Manager）里面選擇數據庫服務器，按右鍵，選擇“屬性”，在“服務器設置”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
u master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
八、設置test為緊急修復模式 。
update sysdatabas t status=-32768 where dbid=DB_ID('test')
此時可以在企業管理器（SQL Server Enterpri Manager）里面看到該數據庫處于“只讀\置疑\脫機\緊急模式”可以看到數據庫里面的表，但是僅僅有系統表。
九、下面執行真正的恢復操作，用dbcc rebuild_log命令來重建數據庫日志文件（重建路徑根據你實際的數據庫路徑來）。
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
執行過程中，如果遇到下列提示信息：
服務器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定數據庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明您的其他程序正在使用該數據庫，如果剛才您在八步驟中使用企業管理器打開了test庫的系統表，那么退出企業管理器就可以了。
正確執行完成的提示應該類似于：
警告: 數據庫 'test' 的日志已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置數據庫選項，并且可能需要刪除多余的日志文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在企業管理器里面會看到數據庫的狀態為“只供DBO使用”。此時可以訪問數據庫里面的用戶表了。
十、驗證數據庫一致性。（次步驟可省略）
dbcc checkdb('test')
一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在數據庫 'test'中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
十一、設置數據庫為正常狀態
sp_dboption 'test','dbo u only','fal'
如果沒有出錯，那么恭喜，現在就可以正常的使用恢復后的數據庫啦。
十二、最后一步，我們要將步驟七中設置的“允許對系統目錄直接修改”一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在企業管理器里面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
對于只有.mdf文件的sql2000數據庫恢復，從第三步開始做就行了。
最好的方法為先分離然后附加看下
1．我們SQL SERVER企業管理器新建立一個供恢復使用的同名數據庫(注意：要跟問題數據庫同名，本例中為myDb)。
2．停掉數據庫服務器。
3．將剛才生成的數據庫的日志文件myDb_log.ldf刪除（本例中的示列數據庫名，實際使用您自己的數據庫名稱），用剛才備份的數據庫mdf文件覆蓋新生成的數據庫數據文件myDb_data.mdf。
4．啟動數據庫服務器。此時會看到數據庫myDb的狀態為“置疑”。這時候不能對此數據庫進行任何操作。
5．設置數據庫允許直接操作系統表。此操作可以在SQL Server Enterpri Manager里面選擇數據庫服務器，按右--鍵，選擇“屬性”，在“服務器設置”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
u master
go
sp_configure 'allow updates',1
go
reconfigure with override
go F．設置myDb為緊急修復模式
在查詢管理器里設置如下命令：
update sysdatabas t status=-32768 where dbid=DB_ID('stib')此時可以在SQL Server Enterpri Manager里面看到該數據庫處于“只讀\置疑\脫機\緊急模式”可以看到數據庫里面的表，但是僅僅有系統表
6．下面執行真正的恢復操作，重建數據庫日志文件
dbcc rebuild_log('stib','E:\zz\stib_log.ldf')警告: 數據庫 'myDb' 的日志已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置數據庫選項，并且可能需要刪除多余的日志文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterpri Manager里面會看到數據庫的狀態為“只供DBO使用”。此時可以訪問數據庫里面的用戶表了。
7．驗證數據庫一致性（可省略）
dbcc checkdb('stib')一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在數據庫 'myDb' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
sp_dboption 'stib','single ur','true'--設置為單用戶
dbcc checkdb('stib','REPAIR_ALLOW_DATA_LOSS')--這個語句可能執行幾遍之后有效
sp_dboption 'stib','single ur','fal'--取消單用戶
8．設置數據庫為正常狀態
sp_dboption 'stib','dbo u only','fal'
9．最后一步，我們要將步驟E中設置的“允許對系統目錄直接修改”一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterpri Manager里面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
到此數據庫置疑問題解決。
如何修復SQL數據庫置疑 修復SQL數據庫置疑方法
1、在實際的操作中由于突然斷電或者突然斷網造成數據庫置疑（在企業管理器中數據庫后面出現置疑兩個字），下面我們通過以下方法來進行修復置疑的數據庫。
2、我們使用默認方式建立一個供恢復使用的數據庫(如test)。可以在SQL Server Enterpri Manager里面建立。
3、停掉數據庫服務器。
4、將剛才生成的數據庫的日志文件test_log.ldf刪除，用要恢復的數據庫mdf文件覆蓋剛才生成的數據庫數據文件test_data.mdf。
5、啟動數據庫服務器。此時會看到數據庫test的狀態為“置疑”。這時候不能對此數據庫進行任何操作。
6、設置數據庫允許直接操作系統表。此操作可以在SQL Server Enterpri Manager里面選擇數據庫服務器，按右鍵，選擇“屬性”，在“服務器設置”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
sql2000數據庫置疑怎么處理?
1、新建一同名數據庫（文件名，文件組都和原來的一樣），然后停止數據庫服務，用原來文件替換新建的數據庫文件，啟動數據庫，該數據庫被設為suspect
2、把數據庫改成緊急模式：
sp_configure
'allow',
1
reconfigure
with
override
update
sysdatabas
t
status
=
32768
where
name
=
'數據庫名'
3、把LDF文件改名，再執行
DBCC
REBUILD_LOG
('數據庫名',
'E:\fdzz\databa\fdzz1204_Log.LDF'
)
4、恢復數據庫緊急模式
update
sysdatabas
t
status
=
0
where
name
=
'數據庫名'
如果不行,你就去看這篇文章.
http://www.flashmayi.com/article/show.php?id=8363&spn=1
如何解決SQL Server數據庫置疑問題
您好，是這樣的：
1.首先確認已經備份了.mdf和.ldf文件。
2. 在SQL Server中新建一個同名的數據庫，然后停止SQL Server服務。
3. 用原有的.mdf和.ldf文件覆蓋新建數據庫對應的.mdf和.ldf文件。
4. 重新啟動SQL Server服務，這是應該會看到這個數據庫處于置疑（Suspect）狀態。
5. 在SQL查詢分析器中執行以下命令，以允許更新系統表：u mastergosp_configure "allow updates",1reconfigurewithoverridego。
6. 將這個數據庫置為緊急模式：update sysdatabas t status = 32768 where name="db_name"go。
7. 使用DBCC CHECKDB命令檢查數據庫中的錯誤：DBCC CHECKDB("db_name")GO。
8. 如果DBCC CHECKDB命令失敗，請轉至第10步，否則先將數據庫置為單用戶模式，再嘗試對其進行修復：sp_dboption "db_name","single
ur","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_retstatus "db_name"
清除數據庫的單用戶模式狀態：sp_dboption "db_name","single ur","fal"
重新啟動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命令檢查并修復數據庫中。
數據庫為什么會置疑？有什么條件會產生這個原因？
1 SQL Server所在分區空間是否夠？數據庫文件大小是否達到最大文件限制？
2 數據庫文件損壞或被非正常刪除時出現這種情況
3 病毒防火墻的掃描也會引起數據庫置疑
INF: Consideration for a virus scanner on a computer that is running SQL Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;309422
If the virus sweep has opened a databa file and still has it open when SQL Server tries to open the databa (such as when SQL Server starts or when SQL Server opens a databa that AutoClo has clod), the databa to which the file belongs might be marked suspect. The SQL Server databa files typically have the .mdf, .ldf, and .ndf file suffixes.
4 當SQL Server啟動時，將會嘗試獲得對數據庫文件的排他訪問權，如果此時該文件被其他程序占用，或者遺失，數據庫將會被標記為置疑。
PRB: Missing device caus databa to be marked suspect
http://support.microsoft.com/kb/180500/EN-US/
sql數據庫置疑，錯誤代碼926，請問要如何修復？
請輸入你的答案...
數據庫926錯誤解決方案在做任何操作前首先備份數據庫的數據文件和日志文件！以及最新的備份文件！第一種解決方法：先刪除報錯數據庫，再新建一同名數據庫，然后暫停Service
manager（及sql
rver
服務）
，刪除庫文件和日志文件再啟動Service
manager
，使用單數據文件恢復數據庫命令恢復數據庫。例：打開sql
rver/tools/sql
rver
query
analyzer
執行下面操作
EXEC
sp_attach_single_file_db
@dbname
=
'pubs',
@physname
=
'c:\mssql7\data\pubs.mdf'
說明：‘pubs’為要恢復的數據庫名稱，‘c:\mssql7\data\pubs.mdf’為要恢復的數據庫的庫文件的具體路徑和文件名稱。再重新啟動一下rvice
manager
，看能否正常打開處理后的數據庫；如果不可以再使用第二種方案。第二種解決方法：打開sql
rver/tools/sql
rver
query
analyzer
執行下面操作
USE
MASTER
GO
sp_configure
'allow
update',1
RECONFIGURE
WITH
OVERRIDE
GO
UPDATE
sysdatabas
t
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
rver數據庫間復制對象和數據’。當選擇從源數據庫復制表和視圖時一定要選擇全部表！
2，
當選擇‘從sql
rver數據庫間復制對象和數據’時，在‘導入導出向導’對話框中去除‘使用默認選項’的選中標志；再在打開‘選項’對話框，去除以下三項的選中標志。A,復制數據用戶和數據庫角色；B，復制sql
rver
登陸；C，復制對象及權限。
3，
在使用‘從sql
rver數據庫間復制對象和數據’時，有時會出現單張表導入失敗，這時有時會在導入結束時提示那幾張表導入失敗有時不提示，如果提示，就再使用‘從源數據庫復制表和視圖’并選中導入失敗的表重新導入一遍；如果不提示就只能在一張張表打開查看了，發現空表后再使用‘從源數據庫復制表和視圖’導入需要導入的表！導入成功后再刪除sql
rver
7.0機器上處于緊急狀態的數據庫，再新建一個同名數據庫，建好后再使用sql
2000的數據庫導出功能導出到此數據庫中，在導出過程中同樣要注意導入時的注意事項！
