sqlserver2000資料庫修復實戰經驗DBCC

DBCC         

REPAIR_FAST 進行小的、不耗時的修復操作，如修復非聚集索引中的附加鍵。這些修復可以很快完成，並且不會有丟失資料的危險。
　　REPAIR_REBUILD 執行由 REPAIR_FAST 完成的所有修復，包括需要較長時間的修復（如重建索引）。執行這些修復時不會有丟失資料的危

險。

　　第一次執行，我們會發現：
　　DBCC results for 'TABLE_NAME'.
　　There are 1 rows in 1 pages for object 'TABLE_NAME'.
　　The error has been repaired.
　　CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).
　　CHECKDB fixed 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).
　　這樣的資訊有很多，並且有“The error has been repaired”的提示。不過到最後還是有這樣的資訊：
　　CHECKDB found 0 allocation errors and 19 consistency errors in database 'POS_DB'.
　　CHECKDB fixed 0 allocation errors and 19 consistency errors in database 'POS_DB'.
　　再次執行，還是有同樣的錯誤。糟糕:=)看來這種方式是無法修復這樣測錯誤。

　　失敗！！！
再仔細看看SQLSERVER BOL發現CHECKDB還有一個非常有用的引數PHYSICAL_ONLY

　　PHYSICAL_ONLY
　　僅限於檢查頁和記錄標題物理結構的完整性，以及頁物件 ID 和索引 ID 與分配結構之間的一致性。該檢查旨在以較低的開銷檢查資料庫

的物理一致性，同時還檢測會危及使用者資料安全的殘缺頁和常見的硬體故障。PHYSICAL_ONLY 始終意味著 NO_INFOMSGS，並且不能與任何修復

選項一起使用。

　　再次執行：
　　DBCC CHECKDB('POS_DB') with NO_INFOMSGS,PHYSICAL_ONLY
　　然後再執行：
　　DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
　　這次會返回一些8952.8956的錯誤資訊:
　　Server: Msg 8952, Level 16, State 1, Line 1
　　Table error: Database 'POS_DB', index 'POS_REFER.Idx2_POS_REFER' (ID 861246123) (index ID 　　　2). Extra or invalid key

for the keys:

　　Server: Msg 8956, Level 16, State 1, Line 1
　　Index row (1:26315:23) with values (PLU_ID = '6922825200240' and PRD_AGGR_ID = 10006 and 　　　EVNT_ID = NULL and

RGST_MDE = 0 and SUBPRD_NBR = 0 and STR_ID = 12 and PRD_AGGR_ID = 10006 and SUBPRD_NBR = 0 and STR_ID = 12 and PLU_ID =

'6922825200240' and EVNT_ID = NULL and RGST_MDE = 0) points to the data row identified by ().

　　根據MSDN上的說明：
　　This problem does not cause any data or index corruption. The problem is in the metadata which is corrected only by

dropping and re-creating the indexes.
　　這些問題不會引起資料或索引的損壞，這些問題的後設資料是正確的，只是刪除再重新建立索引。
看來問題是修改了。

　　再次執行DBCC CHECKDB('POS_DB'),再次執行:DBCC CHECKDB('POS_DB'),message沒有錯誤資訊。

　　ok！成功修復:-)

　　4.檢查修復後的資料庫並且備份資料庫
檢查DBCC CHECKDB報錯的相關表，和沒有執行DBCC之前的記錄數進行比較，發現有一個表少了40條記錄。鬱悶:-<

　　5.總結

　　1.RAID5並不能保證SQLSERVER 2000 資料庫的資料檔案的完整性；
　　2.SQLERVER 2000的備份程式不驗證資料庫檔案的資料完整性；如果你的資料檔案有問題，備份時也不圖示；
　　3.DBCC CHECKDB的repair_allow_data_loss並不是非常安全的，不能修復所有的錯誤，即使是對不完整頁（TORN PAGE）的修復也會著成數

據丟失；
　　4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS引數無法修復所有的錯誤;

　　參考文章:
　　
　　
　　
　　
　　
　　

文章出處：   

 

 

 

------------------------------------- 

 

 

在 Microsoft® SQL Server™ 2000 中，可以在使用者使用資料庫時執行 DBCC CHECKDB，因為 DBCC CHECKDB 在檢查每個資料庫表時在表上控制的鎖的型別均更改。

在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在資料庫的每個表上執行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享鎖 (S)，因而阻塞了所有的資料修改語言 (DML) 語句。

在 SQL Server 2000 中，當檢查表時 DBCC CHECKDB 在表上控制架構鎖以防止後設資料的更改，因而允許在正在檢查的表上使用除任何資料定義語言 (DDL) 語句之外的 DML 語句。該變化對於決定何時執行 DBCC CHECKDB 提供了更大的靈活性，因為 DBCC CHECKDB 並不完全拒絕使用者對系統的使用。

DBCC CHECKDB 是大量佔用 CPU 和磁碟的操作。每一個需要檢查的資料頁都必須首先從磁碟讀入記憶體。另外，DBCC CHECKDB 使用 tempdb 排序。

如果在 DBCC CHECKDB 執行時動態執行事務，那麼事務日誌會繼續增長，因為 DBCC 命令在完成日誌的讀取之前阻塞日誌截斷。

建議在伺服器負荷較少的時候執行 DBCC CHECKDB。如果在負荷高峰期執行 DBCC CHECKDB，那麼事務吞吐量效能和 DBCC CHECKDB 完成時間效能都會受到影響。

要獲得好的 DBCC 效能的一些建議

• 在系統使用率較低時執行 CHECKDB。
  
  
• 請確保未同時執行其它磁碟 I/O 操作，例如磁碟備份。
  
  
• 將 tempdb 放到單獨的磁碟系統或快速磁碟子系統中。
  
  
• 允許 tempdb 在驅動器上有足夠的擴充套件空間。使用帶有 ESTIMATE ONLY 的 DBCC 估計 tempdb 將需要多少空間。
  
  
• 避免執行佔用大量 CPU 的查詢或批處理作業。
  
  
• 在 DBCC 命令執行時，減少活動事務。
  
  
• 使用 NO_INFOMSGS 選項顯著減少處理和 tempdb 的使用。

考慮使用帶有 PHYSICAL_ONLY 選項的 DBCC CHECKDB 來檢查頁和記錄首部的物理結構。當硬體導致的錯誤被置疑時，這個操作將執行快速檢查。

SQL2000資料修復命令DBCC用法

MS Sql Server 提供了很多資料庫修復的命令，當資料庫質疑或是有的無法完成讀取時可以嘗試這些修復命令。
1. DBCC CHECKDB
重啟伺服器後，在沒有進行任何操作的情況下，在SQL查詢分析器中執行以下SQL進行資料庫的修復，修復資料庫存在的一致性錯誤與分配錯誤。
use master
declare @databasename varchar(255)
set @databasename='需要修復的資料庫實體的名稱'
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('需要修復的資料庫實體的名稱') 檢查資料庫是否仍舊存在錯誤。注意：修復後可能會造成部分資料的丟失。

2. DBCC CHECKTABLE
如果DBCC CHECKDB 檢查仍舊存在錯誤，可以使用DBCC CHECKTABLE來修復。
use 需要修復的資料庫實體的名稱
declare @dbname varchar(255)
set @dbname='需要修復的資料庫實體的名稱'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修復的資料表的名稱',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修復的資料表的名稱',REPAIR_REBUILD)
------把’ 需要修復的資料表的名稱’更改為執行DBCC CHECKDB時報錯的資料表的名稱
exec sp_dboption @dbname,'single user','false'

3. 其他的一些常用的修復命令
DBCC DBREINDEX 重建指定資料庫中表的一個或多個索引
用法：DBCC DBREINDEX (表名,’’) 修復此表所有的索引。

4.DBCC SHRINKFILE (裝置檔名或id, 目標大小)

DBCC SHRINKFILE (tempdev, 200)
收縮資料庫檔案tempdev到200MB
DBCC SHRINKFILE (templog, 100)
收縮資料庫檔案templog到100MB

清除日誌檔案
backup log 資料庫名 with NO_LOG
dbcc shrinkDatabase(資料庫名)

例：將tempdb檔案設定大小為50M：
USE tempdb
DBCC SHRINKFILE(tempdb,50)