資料庫置疑
Ⅰ 資料庫為什麼會置疑有什麼條件會產生這個原因
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 database file and still has it open when SQL Server tries to open the database (such as when SQL Server starts or when SQL Server opens a database that AutoClose has closed), the database to which the file belongs might be marked suspect. The SQL Server database files typically have the .mdf, .ldf, and .ndf file suffixes.
4 當SQL Server啟動時,將會嘗試獲得對資料庫文件的排他訪問權,如果此時該文件被其他程序佔用,或者遺失,資料庫將會被標記為置疑。
PRB: Missing device causes database to be marked suspect
http://support.microsoft.com/kb/180500/EN-US/
Ⅱ SQL 資料庫置疑問題
千萬不要用xp裝sqlserver,你用server2003裝sql企業版,肯定不會出現這些問題。
我之前的一家公司,也是經常出現這類置疑問題。安裝2003與企業版後完美無誤。
Ⅲ 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 資料庫置疑
修復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 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資料庫質疑的原因及解決辦法
sql資料庫質疑是設置錯誤造成的,解決方法為:
1、通過DBCC CHECKCB('DBName') 來檢測資料庫異常的原因,如果可以檢測到資料庫的異常,其中紅色部分即時數據目前存在的問題,我們也在檢測結果最後看到數據的總體的錯誤情況的匯總。
Ⅶ 資料庫被置疑了,怎麼處理
請查看你安裝的時候產生的Data數據存放文件,裡面如果不存在被質疑的資料庫,那麼就是可能你在附加或還原資料庫的時候把數據文件存放的位置放在了外部,導致數據文件路徑出錯,以致於發生了資料庫被質疑的可能.
Ⅷ 資料庫置疑怎樣解決
企業管理器--右鍵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資料庫之間復制對象和數據"
--把"包含擴展屬性"選上,其他的根據需要選擇
--最後完成
Ⅸ 資料庫置疑了怎麼處理
解決由於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
到此資料庫置疑問題解決。
Ⅹ 資料庫置疑是什麼
當資料庫主文件丟失或者和伺服器和資料庫文件丟失連接時就這樣。。。