[轉]mssql 資料表修複方法

From : http://hi.baidu.com/ylj798/blog/item/4878077ab64fe7ea2f73b300.html

有的時候發現查詢資料庫會出現以下類似的提示：

[Microsoft][ODBC SQL Server Driver][SQL Server]text、ntext 或 image 節點的頁 (1:220)，槽 14 不存在。
[Microsoft][ODBC SQL Server Driver][SQL Server]通訊連結失敗
[Microsoft][ODBC SQL Server Driver][SQL Server]警告: 嚴重錯誤 7105 發生於 10 7 2008 10:15AM

這就說明資料表出現了問題了，需要進行修複了，修複的方法很簡單，在SQL 查詢分析器裡執行以下一段程式就可以了，不過要記得不要選中要修複的資料庫，因為該操作是再單使用者下進行的。

USE MASTER
GO
sp_dboption '資料庫名', 'single user', 'true'
Go
DBCC CHECKDB('資料庫名', REPAIR_ALLOW_DATA_LOSS)
Go
USE 資料庫名
go
exec sp_msforeachtable 'DBCC CHECKTABLE("表名",REPAIR_ALLOW_DATA_LOSS)'
exec sp_msforeachtable 'DBCC DBREINDEX("表名")'
go
sp_dboption '資料庫名', 'single user', 'false'
Go

執行完你就會發現一切都ok了，呵呵。

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

DBCC CHECKTABLE

DBCCCHECKTABLE('table_name'|'view_name'[,{NOINDEX|index_id}|,{REPAIR_ALLOW_DATA_LOSS|REPAIR_FAST|REPAIR_REBUILD}])[WITH{ALL_ERRORMSGS][,NO_INFOMSGS][,TABLOCK][,ESTIMATEONLY][,{PHYSICAL_ONLY|DATA_PURITY}]}]

參數：

NOINDEX
指定不應對使用者表的非叢集索引執行會佔用很大系統開銷的檢查。這將減少總執行時間。NOINDEX 不會影響系統資料表，因為完整性檢查的執行對象始終是所有系統資料表索引。

index_id
要進行完整性檢查的索引標識 (ID) 號。如果指定了 index_id，則 DBCC CHECKTABLE 只對該索引以及堆或叢集索引執行完整性檢查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKTABLE 修複發現的錯誤。若要使用修複選項，資料庫必須處於單一使用者模式。

REPAIR_ALLOW_DATA_LOSS (最嚴格的修複方法，會修複所有的索引，還會重建資料頁的儲存分配和指標，並且還會從資料頁中刪去殘缺的資料。 )
嘗試修複報告的所有錯誤。這些修複可能會導致一些資料丟失。

REPAIR_FAST (最簡單的修複模式，只修得非叢集索引的鍵，不會對資料頁進行操作。)
保留文法只是為了向後相容。未執行修複操作。

REPAIR_REBUILD (中等層級的修複方法，對於所有的非叢集索引和索引指標進行完全的檢查和重建。不會對資料頁進行寫入操作。)
既執行次要且不耗時的修複操作（如修複非叢集索引中的額外關鍵字），也執行耗時的修複操作（如重建索引）。執行這些修複時不會有遺失資料的危險。

ALL_ERRORMSGS
顯示不受限制的錯誤數。如果未指定 ALL_ERRORMSGS，則只顯示前 200 個錯誤訊息。

NO_INFOMSGS
取消顯示所有資訊性訊息。

TABLOCK
可使 DBCC CHECKTABLE 獲得一個共用表鎖，而不使用內部資料庫快照集。TABLOCK 可使 DBCC CHECKTABLE 在負荷較重的表上運行得更快，但 DBCC CHECKTABLE 運行時會減少表上可獲得的並發性。

ESTIMATEONLY
顯示運行 DBCC CHECKTABLE 和所有其他指定選項時，所需的 tempdb 空間的估計大小。

PHYSICAL_ONLY
限 製為檢查頁、記錄標題的物理結構以及 B 樹物理結構的完整性。此選項旨在以較低的開銷檢查表的物理一致性，同時，此項檢查還可以檢測可能危及使用者資料安全的殘缺頁和常見的硬體故障。在 SQL Server 2005 中，DBCC CHECKTABLE 完整啟動並執行時間可能比早期版本要長得多。導致此行為發生的原因如下：

邏輯檢查比較全面。
要檢查的某些基礎結構更為複雜。
在 SQL Server 2005 中引入了許多新的檢查，以包含新增功能。
因 此，使用 PHYSICAL_ONLY 選項可能會使 DBCC CHECKTABLE 在大型表上啟動並執行時間短得多，所以對需要頻繁檢查的生產系統，建議使用 DBCC CHECKTABLE。我們仍然建議定期執行 DBCC CHECKTABLE 的完整運行。這些啟動並執行執行頻率取決於各業務和生產環境特定的因素。PHYSICAL_ONLY 始終表示 NO_INFOMSGS，不能與任何修複選項一同使用。

DATA_PURITY
使 DBCC CHECKTABLE 檢查表中是否存在無效或越界的列值。例如，DBCC CHECKTABLE 檢測到日期和時間值大於或小於 datetime 資料類型的可接受範圍的列，或者小數位元或精度值無效的 decimal 或近似 numeric 資料類型列。

對於在 SQL Server 2005 中建立的資料庫，預設情況下將啟用列值完整性檢查，並且不需要使用 DATA_PURITY 選項。對於從 SQL Server 的早期版本升級的資料庫，您可以使用 DBCC CHECKTABLE WITH DATA_PURITY 尋找和更正特定表中的錯誤，但是預設情況下不會對該表啟用列值檢查，直到 DBCC CHECKDB WITH DATA_PURITY 在資料庫中正確運行時為止。然後，DBCC CHECKDB 和 DBCC CHECKTABLE 將預設檢查列值完整性。

CSDN 討論資料