『壹』 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資料庫質疑怎麼辦
因為你把資料庫的物理文件刪除了，但是資料庫中還有。
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資料庫質疑的原因及解決辦法
sql資料庫質疑是設置錯誤造成的，解決方法為：
1、通過DBCC CHECKCB('DBName') 來檢測資料庫異常的原因，如果可以檢測到資料庫的異常，其中紅色部分即時數據目前存在的問題，我們也在檢測結果最後看到數據的總體的錯誤情況的匯總。
『肆』 如何分析sql2000資料庫置疑的原因
一般在
安裝目錄\MSSQL\Data下
出現這種情況是你把mdf弄丟了
沒有其他備份數據就沒了
不過你可以下載個
硬碟數據恢復
先看看能不能把mdf
文件恢復
過來，不能就沒戲了
『伍』 SQL資料庫質疑怎麼解決
1,停止sql服務管理器，將日誌文件 aaa.ldf 改成 aaa1.ldf(重新命名)
2，再開啟sql服務管理器，打開查詢分析器：依次執行
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
update sysdatabases set status=-32768 where dbid=DB_ID('aaa')
go
dbcc rebuild_log('aaa','d:\aaa_log.ldf') -----一定要是資料庫路徑，如果不對要改下
go
dbcc checkdb('aaa')
go
sp_dboption 'aaa','dbo use only','false'
go
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資料庫置疑怎麼辦
--前提是硬碟沒問題.如果硬碟本來就有問題.次方法可能無效
那個資料庫屬性里 有個許可權 把只限於管理員的那個勾去掉就好了
--1.獲取資料庫路徑
use master
go
select name,reverse(substring(reverse(filename),charindex('\',reverse(filename)),1000)) from sysdatabases
--2.啟動sql 服務
use master
go
sp_configure 'allow update',1
reconfigure with override
go
update sysdatabases set status = 32768 where name = 'hydee'
go
--2_1: 停止sql 服務, 刪掉日誌文件
--2_2: 啟動sql 服務,重建資料庫日誌文件
dbcc rebuild_log('hydee','F:\hydee\data\hydee_log.ldf') --最好在原路徑上面吧.文件夾一點要原來就存在,不然會提示錯誤.
go
use master
update sysdatabases set status = 8 where name = 'hydee'
Go
sp_configure'allow updates',0
reconfigure with override
Go
--這個時候.資料庫應該已經不是置疑的.並且可以使用了.只是有部分損壞
--3.修復資料庫
use master
declare @databasename varchar(255)
set @databasename='hydee'
exec sp_dboption @databasename, N'single', N'true'
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'
--最後修復完.再dbcc checkdb一次唄,暫時還沒試過不行的.
--這樣可以省去重新改傳輸序號.而且有些店還沒有備份的.
-------------------------------------------------------------
『捌』 如何解決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的資料庫導出功能導出到此資料庫中，在導出過程中同樣要注意導入時的注意事項！