SQLServer 數(shù)據(jù)修復(fù)命令DBCC一覽
更新時間:2009年11月08日 23:41:16 作者:
MS Sql Server 提供了很多數(shù)據(jù)庫修復(fù)的命令,當數(shù)據(jù)庫質(zhì)疑或是有的無法完成讀取時可以嘗試這些修復(fù)命令。
1. DBCC CHECKDB
重啟服務(wù)器后,在沒有進行任何操作的情況下,在SQL查詢分析器中執(zhí)行以下SQL進行數(shù)據(jù)庫的修復(fù),修復(fù)數(shù)據(jù)庫存在的一致性錯誤與分配錯誤。
use master
declare @databasename varchar(255)
set @databasename='需要修復(fù)的數(shù)據(jù)庫實體的名稱'
exec sp_dboption @databasename, N'single', N'true' --將目標數(shù)據(jù)庫置為單用戶狀態(tài)
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--將目標數(shù)據(jù)庫置為多用戶狀態(tài)
然后執(zhí)行 DBCC CHECKDB('需要修復(fù)的數(shù)據(jù)庫實體的名稱') 檢查數(shù)據(jù)庫是否仍舊存在錯誤。注意:修復(fù)后可能會造成部分數(shù)據(jù)的丟失。
2. DBCC CHECKTABLE
如果DBCC CHECKDB 檢查仍舊存在錯誤,可以使用DBCC CHECKTABLE來修復(fù)。
use 需要修復(fù)的數(shù)據(jù)庫實體的名稱
declare @dbname varchar(255)
set @dbname='需要修復(fù)的數(shù)據(jù)庫實體的名稱'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修復(fù)的數(shù)據(jù)表的名稱',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修復(fù)的數(shù)據(jù)表的名稱',REPAIR_REBUILD)
------把' 需要修復(fù)的數(shù)據(jù)表的名稱'更改為執(zhí)行DBCC CHECKDB時報錯的數(shù)據(jù)表的名稱
exec sp_dboption @dbname,'single user','false'
3. 其他的一些常用的修復(fù)命令
DBCC DBREINDEX 重建指定數(shù)據(jù)庫中表的一個或多個索引
用法:DBCC DBREINDEX (表名,'') 修復(fù)此表所有的索引。
===================================
SQL SERVER數(shù)據(jù)庫的檢測及修復(fù)方法
隨著K/3產(chǎn)品的推廣,要求客戶服務(wù)人員對SQL SERVER數(shù)據(jù)庫的了解也進一步提高。在K/3的使用過程中,數(shù)據(jù)庫文件被頻繁地使用,由于某些原因,數(shù)據(jù)庫有可能被損壞,本文將針對這種情況的數(shù)據(jù)庫檢測及修復(fù)方法做一簡單講解。希望各位在實際工作過程中有新的發(fā)現(xiàn)時,及時給我們提供信息,以便做進一步的更新。
1.1 SQL SERVER數(shù)據(jù)庫的檢測
SQL SERVER提供了數(shù)據(jù)庫檢測的命令,可用DBCC CHECKDB對數(shù)據(jù)庫中各個對象的分配及結(jié)構(gòu)的正確性進行檢測,并可通過一參數(shù)控制,將所有的錯誤信息顯示出來。其語法如下:
DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
}]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
參數(shù)說明:
'database_name'代表被檢測的數(shù)據(jù)庫實體名;
NOINDEX指非系統(tǒng)表的非聚族索引不檢測;
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修復(fù)發(fā)現(xiàn)的錯誤,其中REPAIR_ALLOW_DATA_LOSS代表,若此錯誤不能修復(fù)時,系統(tǒng)將直接刪除相關(guān)數(shù)據(jù)。帶此三個參數(shù)的任一個時,數(shù)據(jù)庫必須處于單用戶模式,可在Enterprise Manager中的數(shù)據(jù)庫屬性中設(shè)置;
ALL_ERRORMSGS代表將檢測到的錯誤信息全部顯示出來,否則,對于每張表最多只顯示200條錯誤信息;
NO_INFOMSGS代表隱藏所有的信息及占用空間的報告。
經(jīng)過檢測,對于錯誤的對象,將以O(shè)BJECT ID的形式報告具體出錯的信息,可根據(jù)OBJECT ID到系統(tǒng)表sysobjects中查找到相關(guān)的表,即NAME。
1.2 SQL SERVER問題數(shù)據(jù)庫的修復(fù)
經(jīng)過數(shù)據(jù)庫檢測后,可針對出現(xiàn)的問題采取相應(yīng)的措施進行處理。如通過檢測后,發(fā)現(xiàn)對象的物理存放存在問題,可用DBCC CHECKALLOC來進行修復(fù):
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系統(tǒng)對象的索引出錯,則可用DBCC DBREINDEX進行修復(fù):
DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]
以上兩種情況,也可直接使用DBCC CHECKDB(‘db_name',repair_rebuild)來修復(fù)。
另外一種情況是在進行檢測時,提示無法建立數(shù)據(jù)連接,此時表明,數(shù)據(jù)庫已損壞。對于這種情況,我們可采取如下措施來嘗試修復(fù)。
首先,在SQL Enterprise中新建一數(shù)據(jù)庫(如數(shù)據(jù)庫名為test),建好數(shù)據(jù)庫后,停止SQL Server Service Manager,并將客戶數(shù)據(jù)庫的MDF文件更名為test _data.mdf(即新建數(shù)據(jù)庫的主文件名),然后用更名后的文件覆蓋新建數(shù)據(jù)庫同名文件,接著,啟動SQL Server Service Manager。對Master數(shù)據(jù)庫將系統(tǒng)表設(shè)置為可更改狀態(tài)
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
將數(shù)據(jù)庫設(shè)為緊急狀態(tài):
update sysdatabases set status = 32768 where database '
停止并重新啟動SQL Server Service Manager,并重建Log文件:
DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
將數(shù)據(jù)庫設(shè)置為單用戶模式,然后進行檢測:
sp_dboption ' test ', 'single user', 'true'
DBCC CHECKDB(' test ')
Go
此數(shù)據(jù)庫執(zhí)行CHECKDB的過程中發(fā)現(xiàn)一些表的索引被破壞,于是針對具體的表進行重建索引的操作:
DBCC DBREINDEX(表名)
如執(zhí)行以上操作仍然不能解決,若索引破壞的表是臨時表或不是關(guān)鍵表,則可從新建賬套中引入,若是主表,則可能通過近期的備份來(部份)恢復(fù)。若沒有一個備份,則無法修復(fù)。
1.3 SQL Server數(shù)據(jù)庫為什么易損壞呢?
以下是微軟提供的一些可能引起數(shù)據(jù)庫損壞的原因及一些預(yù)防措施:
操作問題,包括冷起動機器、熱拔硬盤、刪除一些數(shù)據(jù)庫文件;
硬件問題,包括磁盤控制器的問題;
操作系統(tǒng)問題,包括與系統(tǒng)相關(guān)的一些致命錯誤。
1.4 預(yù)防措施:
1、定期/不定期執(zhí)行CHKDSK(不帶參數(shù)),以檢測硬盤物理結(jié)構(gòu)并修復(fù)一些CHKDSK報告的問題;
2、常備份數(shù)據(jù)。
1.5 應(yīng)用數(shù)據(jù)庫修復(fù)舉例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工輸入
---------執(zhí)行一般性修復(fù)還存在問題時,進行允許數(shù)據(jù)丟失的修復(fù)
---------許數(shù)據(jù)丟失的修復(fù)要求在單用戶下進行,此時請退出中間層,客戶端,sql的其他模塊
---所有功能退出,在查詢分析器master里設(shè)置數(shù)據(jù)庫為單用戶
exec sp_dboption @databasename, N'single', N'true'
-----在查詢分析器master里,進行修復(fù)數(shù)據(jù)庫
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
------還原數(shù)據(jù)庫狀態(tài)
exec sp_dboption @databasename, N'single', N'false'
第2章數(shù)據(jù)庫日志損壞的修復(fù)
請遵照如下步驟來試圖重建數(shù)據(jù)庫事務(wù)日志.
注意: 由于事務(wù)日志丟失, 數(shù)據(jù)庫可能有沒有提交的數(shù)據(jù).
注:都要替換成真實的數(shù)據(jù)庫名字
2.1 步驟1:
創(chuàng)建一個新的數(shù)據(jù)庫,命名為原來數(shù)據(jù)庫的名字.
2.2步驟2:
停止SQL Server
2.3步驟3:
把老數(shù)據(jù)庫的MDF文件替換新數(shù)據(jù)庫的相應(yīng)的MDF文件, 并把LDF文件刪除
2.4步驟4:
重新啟動SQL Server 服務(wù),然后運行如下命令:
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
begin tran
update sysdatabases set status = 32768 where db_name'
-- Verify one row is updated before committing
commit tran
2.5步驟5:
停止SQL然后重新啟動SQL Server 服務(wù),然后運行如下命令:
DBCC TRACEON (3604)
DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')
Go
2.6步驟6:
停止SQL然后重新啟動SQL Server 服務(wù),然后運行:
use master
update sysdatabases set status = 8 where
Go
sp_configure 'allow updates', 0
reconfigure with override
Go
2.7步驟7:
運行dbcc checkdb(db_name)檢查數(shù)據(jù)庫的完整性.
第3章 數(shù)據(jù)庫質(zhì)疑的一般處理
1、執(zhí)行如下SQL(打開修改系統(tǒng)表的開關(guān)):
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
2、修改數(shù)據(jù)庫Master中的表:sysdatabases
將 status字段數(shù)值更改為4
3、再執(zhí)行如下SQL:
EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE。
重啟服務(wù)器后,在沒有進行任何操作的情況下,在SQL查詢分析器中執(zhí)行以下SQL進行數(shù)據(jù)庫的修復(fù),修復(fù)數(shù)據(jù)庫存在的一致性錯誤與分配錯誤。
use master
declare @databasename varchar(255)
set @databasename='需要修復(fù)的數(shù)據(jù)庫實體的名稱'
exec sp_dboption @databasename, N'single', N'true' --將目標數(shù)據(jù)庫置為單用戶狀態(tài)
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--將目標數(shù)據(jù)庫置為多用戶狀態(tài)
然后執(zhí)行 DBCC CHECKDB('需要修復(fù)的數(shù)據(jù)庫實體的名稱') 檢查數(shù)據(jù)庫是否仍舊存在錯誤。注意:修復(fù)后可能會造成部分數(shù)據(jù)的丟失。
2. DBCC CHECKTABLE
如果DBCC CHECKDB 檢查仍舊存在錯誤,可以使用DBCC CHECKTABLE來修復(fù)。
use 需要修復(fù)的數(shù)據(jù)庫實體的名稱
declare @dbname varchar(255)
set @dbname='需要修復(fù)的數(shù)據(jù)庫實體的名稱'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修復(fù)的數(shù)據(jù)表的名稱',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修復(fù)的數(shù)據(jù)表的名稱',REPAIR_REBUILD)
------把' 需要修復(fù)的數(shù)據(jù)表的名稱'更改為執(zhí)行DBCC CHECKDB時報錯的數(shù)據(jù)表的名稱
exec sp_dboption @dbname,'single user','false'
3. 其他的一些常用的修復(fù)命令
DBCC DBREINDEX 重建指定數(shù)據(jù)庫中表的一個或多個索引
用法:DBCC DBREINDEX (表名,'') 修復(fù)此表所有的索引。
===================================
SQL SERVER數(shù)據(jù)庫的檢測及修復(fù)方法
隨著K/3產(chǎn)品的推廣,要求客戶服務(wù)人員對SQL SERVER數(shù)據(jù)庫的了解也進一步提高。在K/3的使用過程中,數(shù)據(jù)庫文件被頻繁地使用,由于某些原因,數(shù)據(jù)庫有可能被損壞,本文將針對這種情況的數(shù)據(jù)庫檢測及修復(fù)方法做一簡單講解。希望各位在實際工作過程中有新的發(fā)現(xiàn)時,及時給我們提供信息,以便做進一步的更新。
1.1 SQL SERVER數(shù)據(jù)庫的檢測
SQL SERVER提供了數(shù)據(jù)庫檢測的命令,可用DBCC CHECKDB對數(shù)據(jù)庫中各個對象的分配及結(jié)構(gòu)的正確性進行檢測,并可通過一參數(shù)控制,將所有的錯誤信息顯示出來。其語法如下:
DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
}]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
參數(shù)說明:
'database_name'代表被檢測的數(shù)據(jù)庫實體名;
NOINDEX指非系統(tǒng)表的非聚族索引不檢測;
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修復(fù)發(fā)現(xiàn)的錯誤,其中REPAIR_ALLOW_DATA_LOSS代表,若此錯誤不能修復(fù)時,系統(tǒng)將直接刪除相關(guān)數(shù)據(jù)。帶此三個參數(shù)的任一個時,數(shù)據(jù)庫必須處于單用戶模式,可在Enterprise Manager中的數(shù)據(jù)庫屬性中設(shè)置;
ALL_ERRORMSGS代表將檢測到的錯誤信息全部顯示出來,否則,對于每張表最多只顯示200條錯誤信息;
NO_INFOMSGS代表隱藏所有的信息及占用空間的報告。
經(jīng)過檢測,對于錯誤的對象,將以O(shè)BJECT ID的形式報告具體出錯的信息,可根據(jù)OBJECT ID到系統(tǒng)表sysobjects中查找到相關(guān)的表,即NAME。
1.2 SQL SERVER問題數(shù)據(jù)庫的修復(fù)
經(jīng)過數(shù)據(jù)庫檢測后,可針對出現(xiàn)的問題采取相應(yīng)的措施進行處理。如通過檢測后,發(fā)現(xiàn)對象的物理存放存在問題,可用DBCC CHECKALLOC來進行修復(fù):
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系統(tǒng)對象的索引出錯,則可用DBCC DBREINDEX進行修復(fù):
DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]
以上兩種情況,也可直接使用DBCC CHECKDB(‘db_name',repair_rebuild)來修復(fù)。
另外一種情況是在進行檢測時,提示無法建立數(shù)據(jù)連接,此時表明,數(shù)據(jù)庫已損壞。對于這種情況,我們可采取如下措施來嘗試修復(fù)。
首先,在SQL Enterprise中新建一數(shù)據(jù)庫(如數(shù)據(jù)庫名為test),建好數(shù)據(jù)庫后,停止SQL Server Service Manager,并將客戶數(shù)據(jù)庫的MDF文件更名為test _data.mdf(即新建數(shù)據(jù)庫的主文件名),然后用更名后的文件覆蓋新建數(shù)據(jù)庫同名文件,接著,啟動SQL Server Service Manager。對Master數(shù)據(jù)庫將系統(tǒng)表設(shè)置為可更改狀態(tài)
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
將數(shù)據(jù)庫設(shè)為緊急狀態(tài):
update sysdatabases set status = 32768 where database '
停止并重新啟動SQL Server Service Manager,并重建Log文件:
DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
將數(shù)據(jù)庫設(shè)置為單用戶模式,然后進行檢測:
sp_dboption ' test ', 'single user', 'true'
DBCC CHECKDB(' test ')
Go
此數(shù)據(jù)庫執(zhí)行CHECKDB的過程中發(fā)現(xiàn)一些表的索引被破壞,于是針對具體的表進行重建索引的操作:
DBCC DBREINDEX(表名)
如執(zhí)行以上操作仍然不能解決,若索引破壞的表是臨時表或不是關(guān)鍵表,則可從新建賬套中引入,若是主表,則可能通過近期的備份來(部份)恢復(fù)。若沒有一個備份,則無法修復(fù)。
1.3 SQL Server數(shù)據(jù)庫為什么易損壞呢?
以下是微軟提供的一些可能引起數(shù)據(jù)庫損壞的原因及一些預(yù)防措施:
操作問題,包括冷起動機器、熱拔硬盤、刪除一些數(shù)據(jù)庫文件;
硬件問題,包括磁盤控制器的問題;
操作系統(tǒng)問題,包括與系統(tǒng)相關(guān)的一些致命錯誤。
1.4 預(yù)防措施:
1、定期/不定期執(zhí)行CHKDSK(不帶參數(shù)),以檢測硬盤物理結(jié)構(gòu)并修復(fù)一些CHKDSK報告的問題;
2、常備份數(shù)據(jù)。
1.5 應(yīng)用數(shù)據(jù)庫修復(fù)舉例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工輸入
---------執(zhí)行一般性修復(fù)還存在問題時,進行允許數(shù)據(jù)丟失的修復(fù)
---------許數(shù)據(jù)丟失的修復(fù)要求在單用戶下進行,此時請退出中間層,客戶端,sql的其他模塊
---所有功能退出,在查詢分析器master里設(shè)置數(shù)據(jù)庫為單用戶
exec sp_dboption @databasename, N'single', N'true'
-----在查詢分析器master里,進行修復(fù)數(shù)據(jù)庫
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
------還原數(shù)據(jù)庫狀態(tài)
exec sp_dboption @databasename, N'single', N'false'
第2章數(shù)據(jù)庫日志損壞的修復(fù)
請遵照如下步驟來試圖重建數(shù)據(jù)庫事務(wù)日志.
注意: 由于事務(wù)日志丟失, 數(shù)據(jù)庫可能有沒有提交的數(shù)據(jù).
注:都要替換成真實的數(shù)據(jù)庫名字
2.1 步驟1:
創(chuàng)建一個新的數(shù)據(jù)庫,命名為原來數(shù)據(jù)庫的名字.
2.2步驟2:
停止SQL Server
2.3步驟3:
把老數(shù)據(jù)庫的MDF文件替換新數(shù)據(jù)庫的相應(yīng)的MDF文件, 并把LDF文件刪除
2.4步驟4:
重新啟動SQL Server 服務(wù),然后運行如下命令:
復(fù)制代碼 代碼如下:
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
begin tran
update sysdatabases set status = 32768 where db_name'
-- Verify one row is updated before committing
commit tran
2.5步驟5:
停止SQL然后重新啟動SQL Server 服務(wù),然后運行如下命令:
DBCC TRACEON (3604)
DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')
Go
2.6步驟6:
停止SQL然后重新啟動SQL Server 服務(wù),然后運行:
復(fù)制代碼 代碼如下:
use master
update sysdatabases set status = 8 where
Go
sp_configure 'allow updates', 0
reconfigure with override
Go
2.7步驟7:
運行dbcc checkdb(db_name)檢查數(shù)據(jù)庫的完整性.
第3章 數(shù)據(jù)庫質(zhì)疑的一般處理
1、執(zhí)行如下SQL(打開修改系統(tǒng)表的開關(guān)):
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
2、修改數(shù)據(jù)庫Master中的表:sysdatabases
將 status字段數(shù)值更改為4
3、再執(zhí)行如下SQL:
EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE。
相關(guān)文章
SQL Server 2005附加數(shù)據(jù)庫時Read-Only錯誤的解決方案
本文我們主要介紹了SQL Server 2005附加數(shù)據(jù)庫時提示Read-Only錯誤的解決方案,需要的朋友可以參考下2015-08-08使用 TOP 子句限制UPDATE 語句更新的數(shù)據(jù)
這篇文章主要介紹了使用 TOP 子句限制UPDATE 語句更新的數(shù)據(jù),需要的朋友可以參考下2014-08-08windows11安裝sqlserver?2016數(shù)據(jù)庫報錯等待數(shù)據(jù)庫引擎恢復(fù)句柄失敗解決辦法
最近安裝SQL?Server遇到這個問題,試過網(wǎng)上幾乎所有辦法,都安裝不上,查了很久才解決,下面這篇文章主要給大家介紹了關(guān)于windows11安裝SQL?server數(shù)據(jù)庫報錯等待數(shù)據(jù)庫引擎恢復(fù)句柄失敗的解決辦法,需要的朋友可以參考下2023-06-06有關(guān)數(shù)據(jù)庫SQL遞歸查詢在不同數(shù)據(jù)庫中的實現(xiàn)方法
這篇文章主要介紹了有關(guān)數(shù)據(jù)庫SQL遞歸查詢在不同數(shù)據(jù)庫中的實現(xiàn)方法的相關(guān)資料,需要的朋友可以參考下2015-10-10