⑴ sql2000 置疑
按照SQLSERVER幫助文件里的方法處理。。。
假設資料庫為TEST：
按以下步驟執行 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
⑵ 如何分析sql2000資料庫置疑的原因
一般在
安裝目錄\MSSQL\Data下
出現這種情況是你把mdf弄丟了
沒有其他備份數據就沒了
不過你可以下載個
硬碟數據恢復
先看看能不能把mdf
文件恢復
過來，不能就沒戲了
⑶ 磁碟空間不足造成的SQL置疑,該怎麼解決
在工作中,遇到過一次sql資料庫狀態"置疑"........ 造成置疑的原因,很可能是因為當時還有節點連接到伺服器上, 在斷開的瞬間,導致了數據文件的操作和 日至文件的紀錄不匹配,不對應.............由於,以前遇到過這樣的問題,那時候資料庫還不時很大,就使用了數據檢查的工具,一條一條紀錄的恢復,盡最大可能的恢復數據記錄,但是,肯定是會丟失部分數據的......而經過一年的數據海量的增加.sql資料庫已經增加到了盡15G,使用數據檢查工具恢復起來很慢,就是恢復一晚上,也不已經能夠完全恢復.........情急之下,1: 想其他方式,恢復置疑的資料庫.....2: 如果1不行,那就,將最近備份的資料庫恢復/*解決過程：1.建一個新庫newdb2.停掉資料庫。刪除新庫的log文件,講metadb.mdf覆蓋newdb.mdf。3.啟動資料庫伺服器。資料庫newdb的狀態為「置疑」。4. 允許對系統目錄直接修改*/use mastergosp_configure 'allow updates',1go reconfigure with overridegoupdate sysdatabases set status=-32768 where dbid=DB_ID('DB_name')/*5．重建log*/dbcc rebuild_log('DB_name','C:\Program Files\Microsoft SQL Server\MSSQL\Data\DB_name_log.ldf')/*6.dbcc檢查 */dbcc checkdb('DB_name')/* 7.設置資料庫為正常狀態 */sp_dboption 'DB_name','dbo use only','false'/* 8 不允許對系統目錄直接修改 */sp_configure 'allow updates',0go reconfigure with overridego如果 SQL Server 因為磁碟可用空間不足，而不能完成資料庫的恢復，那麼 SQL Server 2000 會返回錯誤 1105 並且將 sysdatabases 中的 status 列設為置疑。
⑷ SQL2000資料庫突然置疑 這是什麼原因造成的 我先介紹下現象。
在MS SQLSERVER中一直有這樣的問題,SQLSERVER的狀態"置疑",原因約有以下幾條:
1.錯誤的刪除日誌;
2.硬體(HD)損壞,造成日誌和數據文件寫錯誤;
3.硬碟的空間不夠,比如日誌文件過大;
解決辦法:
最簡單的辦法是有資料庫的全備份,然後恢復即可.
步驟:
1. 刪除原始的資料庫:
USE MASTER
GO
DROP DATABASE DB_SUEPECT
2.建立同名的資料庫:
USE master
GO
CREATE DATABASE DB_SUSPECT
ON
( NAME = DBNAME_DAT,
FILENAME = 'C:',
SIZE = 10,
FILEGROWTH = 5 )
LOG ON
( NAME = 'DBNAME_LOG',
FILENAME = 'g:',
SIZE = 5MB,
FILEGROWTH = 5MB )
GO
3.恢復資料庫:
RESTORE DATABASE DB_SUSPECT
FROM DBNAME_BACKUP.DAT
4.資料庫完整性檢測:
DBCC CHECKDB('DB_SUSPECT')
5.重新啟動MSSQLSERVER服務.
如果沒有全備份,那就要用一些特殊的方法:
1.設置資料庫為緊急模式
Use Master
GO
sp_configure 'allow updates', 1
reconfigure with override
GO
UPDATE sysdatabases SET status = 32768 where name = 'DB_SUSPECT'
GO
2.停掉SQL Server服務:
.Net STOP MSSQLSERVER
3.把原始資料庫的數據文件DBNAME_DAT.MDF,DBNAME_LOG.LDF移走:
4.啟動SQL Server服務:
.Net START MSSQLSERVER
5.重新建立一個同名的資料庫DB_SUSPECT；
USE master
GO
CREATE DATABASE DB_SUSPECT
ON
( NAME = DBNAME_DAT,
FILENAME = 'C:',
SIZE = 10,
FILEGROWTH = 5 )
LOG ON
( NAME = 'DBNAME_LOG',
FILENAME = 'g:',
SIZE = 5MB,
FILEGROWTH = 5MB )
GO
6.設置資料庫運行在單用戶的模式:
USE MASTER
GO
ALTER DATABASE DB_SUSPECT SET SINGLE_USER
GO
7.停掉SQL服務:
.Net STOP MSSQLSERVER
8.把原來的數據文件再覆蓋回來:
9.啟動SQL Server服務:
.Net START MSSQLSERVER
10.重新設置SQLSERVER的狀態:
USE MASTER
GO
EXEC sp_resetstatus "DB_SUSPECT"
11.資料庫完整性檢測:
DBCC CHECKDB('DB_SUSPECT')
12.恢復資料庫為多用戶模式:
USE MASTER
GO
ALTER DATABASE DB_SUSPECT SET MULTI_USER
GO
13.恢復SQLSERVER原始的配置:
USE MATER
GO
UPDATE sysdatabases SET status = 4194320 where name = 'DB_SUSPECT'
GO
14.配置SQLSERVER不允許更新系統表:
USE MASTER
GO
sp_configure 'allow updates', 0
reconfigure with override
GO
15.重新啟動MSSQLSERVER服務:
最好重新啟動操作系統
16.備份資料庫:
可以通過SQLSERVER企業管理器或T-SQL.需要備份MASTER和DB_SUSPECT
補充一點，如果用DOMAIN\USER時,要注意對.MDF.LDF的所在目錄的許可權.
靈驗腳本
遇到這種資料庫置疑情況，就運行下面這個腳本，屢試不爽：
======================================================
--before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
--Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = 'Database_Name'
--Run the following script
exec SP_resetstatus Database_Name
--stop and start the MSDTC at this stage
--After the procere is created, immediately disable
updates to the system tables:
exec sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
⑸ SQL SERVER 2000 重啟資料庫或伺服器以後 出現置疑的問題。
你把你的資料庫文件換一個盤，放置。然後再附加。我以前用sqlserver2005 也出現過類似的問題，不過，我把需要的附加的文件換了一個位置，然後就成功了。這個原因，是你資料庫中存在相同的文件，但是，一時也找不到在哪，所以，就引起附加的沖突了。
⑹ sql2000資料庫經常置疑怎麼處理
修復資料庫前，請做好相關備份。最好不要前後台相連，以免造成不必要的數據丟失。我們以名為「kspos」的資料庫為例。1.首先把服務管理器先停止，把原來置疑的資料庫下的兩個文件拷貝出來，
啟動服務管理器，在企業管理器中刪除該資料庫，然後建立一個同名的數
據庫。停止服務管理器，把置疑的資料庫文件拷貝進去覆蓋。2.運行中輸入「isqlw」,打開查詢分析器。3.輸入語句USE
MASTER
GOSP_CONFIGURE
'ALLOW
UPDATES',1
RECONFIGURE
WITH
OVERRIDE
GOUPDATE
SYSDATABASES
SET
STATUS
=-32768
WHERE
NAME='kspos'
Go使資料庫處於緊急修復模式4.輸入語句：use
kspos
go
dbcc
checkdb
('kspos')
此語句作用在於查詢資料庫的損壞狀況。5.刪除原來的日誌文件，重新建立新的日誌文件。
DBCC
REBUILD_LOG
('kspos','D:\Program
Files\Microsoft
SQL
Server\MSSQL\Data\bw9kyy_01_Log.LDF'
)6.右擊kspos資料庫\屬性\選項\選擇單用戶。7.修復
dbcc
checkdb
('kspos',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS
執行由
REPAIR_REBUILD
完成的所有修復，包括對行和頁進行分配和取消分配以改正分配錯誤、結構行或頁的錯誤，以及刪除已損壞的文本對象。這些修復可能會導致一些數據丟失。修復操作可以在用戶事務下完成以允許用戶回滾所做的更改。如果回滾修復，則資料庫仍會含有錯誤，應該從備份進行恢復。如果由於所提供修復等級的緣故遺漏某個錯誤的修復，則將遺漏任何取決於該修復的修復。修復完成後，備份資料庫。
REPAIR_FAST
進行小的、不耗時的修復操作，如修復非聚集索引中的附加鍵。這些修復可以很快完成，並且不會有丟失數據的危險。
REPAIR_REBUILD
執行由
REPAIR_FAST
完成的所有修復，包括需要較長時間的修復（如重建索引）。執行這些修復時不會有丟失數據的危險。
8.關閉單用戶模式，在企業管理器中直接右擊kspos\屬性\選項，把前面的對
勾去掉即可。
然後在查詢分析器中執行如下語句：
USE
MASTER
GO
SP_CONFIGURE
'ALLOW
UPDATES',0
RECONFIGURE
WITH
OVERRIDE
GO
到此修復工程完畢。註：一般此修復步驟需要5-8次,只需執行第7步即可。 這個方法絕對好用。
⑺ sql資料庫質疑的原因及解決辦法
sql資料庫質疑是設置錯誤造成的，解決方法為：
1、通過DBCC CHECKCB('DBName') 來檢測資料庫異常的原因，如果可以檢測到資料庫的異常，其中紅色部分即時數據目前存在的問題，我們也在檢測結果最後看到數據的總體的錯誤情況的匯總。
⑻ 資料庫「置疑」該怎麼處理
解決由於sql2000日誌文件引起的「置疑」。
日誌有錯誤--------重新附加提示日誌有錯誤。
日誌文件丟失-----丟失了.ldf文件，只有.mdf文件的資料庫重建。
步驟：
一、備份「置疑」資料庫的數據文件，因為日誌文件.ldf出錯，可以只備份.mdf文件。
二、打開企業管理器（SQL Server Enterprise Manager），刪除「置疑」資料庫，如果提示刪除錯誤，可以重啟資料庫伺服器，然後再試。
三、在企業管理器中，新建同名資料庫（假如資料庫為test），注意建立的資料庫名稱，還有數據文件名要保持和原資料庫一致。
四、停止資料庫伺服器。
五、將剛才新建資料庫生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫.mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。
六、啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。
七、設置資料庫允許直接操作系統表。此操作可以在企業管理器（SQL Server Enterprise Manager）裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
八、設置test為緊急修復模式 。
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在企業管理器（SQL Server Enterprise 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 use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
十二、最後一步，我們要將步驟七中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在企業管理器裡面恢復，也可以使用如下語句完成
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 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('stib')此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
6．下面執行真正的恢復操作，重建資料庫日誌文件
dbcc rebuild_log('stib','E:\zz\stib_log.ldf')警告: 資料庫 'myDb' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
7．驗證資料庫一致性（可省略）
dbcc checkdb('stib')一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'myDb' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
sp_dboption 'stib','single user','true'--設置為單用戶
dbcc checkdb('stib','REPAIR_ALLOW_DATA_LOSS')--這個語句可能執行幾遍之後有效
sp_dboption 'stib','single user','false'--取消單用戶
8．設置資料庫為正常狀態
sp_dboption 'stib','dbo use only','false'
9．最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
到此資料庫置疑問題解決。
⑼ 如何修復 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資料庫被置疑！！！高手請進！！
假定資料庫名為AA
1.將AA_log.ldf文件備份到其它目錄下；
2.將源目錄下的AA_log.ldf文件改名為smlog_log_bak.ldf；
3.在查詢分析器中執行以下語句修改資料庫的狀態：
use Master
go
update sysdatabases set status=32768 where name='AA' --修改狀態
go
shutdown with nowait --停止資料庫伺服器
go
4.退出SQL並在命令行模式中執行以下代碼：
sqlservr -c -T3608 -T4022 --安全模式啟動SQL SERVER
5.在查詢分析器中執行以下語句來查看剛剛修改過狀態的資料庫狀態：
select Name,Status from sysdatabases where Name='AA'
6.在查詢分析器中執行以下代碼重建日誌文件：
dbcc traceon(3604) --跟蹤
dbcc rebuild_log('AA','AA') --文件名要有全路徑和擴展名
本步驟如果成功，繼續執行下一步的操作，如果報錯，也可以不管它繼續下一步，也可以將操作之前建立的同名空資料庫日誌文件COPY過來就行。
7.在查詢分析器中執行以下代碼將資料庫置回正常狀態：
update sysdatabases set status=0 where name='AA'
8.重新啟動資料庫後執行以下語句檢查資料庫：
DBCC CHECKDB --如果執行完有錯誤用以下9.10兩步語句修復
9.要修復資料庫必需將資料庫改為單用戶模式：
Exec sp_dboption '資料庫名稱','single user','true'
10.執行以下語句修復資料庫：
DBCC CHECKDB('AA',REPAIR_ALLOW_DATA_LOSS)
11.將資料庫改為多用戶模式：
Exec sp_dboption 'AA','single user','false'
12.重新啟動電腦，成功！