《Microsoft Sql server 2008 Internals》讀書筆記訂閱地址：

http://www.cnblogs.com/downmoon/category/230397.html/rss

《Microsoft Sql server 2008 Internals》索引目錄：

《Microsoft Sql server 2008 Internal》讀書筆記--目錄索引

??■DBCC CHECKDB之外的一致性檢查命令，包含：DBCC CHECKALLOC，DBCC CHECKTABLE，DBCC CHECKFILEGROUP，DBCC CHECKCATALOG，DBCC CHECKIDENT，DBCC CHECKCONSTRAINTS

■DBCC CHECKALLOC

DBCC CHECKALLOC執行下列操作：

◆原始系統分類一致性檢查

◆數據庫的分配一致性檢查

它使用默認的數據庫快照，與DBCC　CHECKED有相同的選項，除了以下：

◆? PHYSICAL_ONLY

◆? REPAIR_REBUILD

◆? DATA_PURITY

這些選項沒有一個對分配一致性檢查有意義。

如果報告消息被允許，它輸出完整的信息，關于頁和數據庫中每個分配單元的已分配分區的數字，還有IAM鏈的第一個IAM頁和根頁。當分配一致性檢查被作為DBCC CHECKED的一部分執行時，以上信息不會返回。例子輸出如下：
DBCC results for 'CorruptDB'.
***************************************************************
Table sys.sysrscols??????????????? Object ID 3.
Index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data). FirstIAM (1:188).
Root (1:189). Dpages 8.
Index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data). 10 pages used in 1
dedicated extents.
Total number of extents is 1.
***************************************************************
<some results removed for brevity>
***************************************************************
Table sys.syscommittab??????????????? Object ID 2137058649.
Index ID 1, partition ID 72057594038583296, alloc unit ID 72057594042580992 (type In-row
data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 1, partition ID 72057594038583296, alloc unit ID 72057594042580992 (type In-row
data). 0 pages used in 0 dedicated extents.
Index ID 2, partition ID 72057594038648832, alloc unit ID 72057594042646528 (type In-row
data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 2, partition ID 72057594038648832, alloc unit ID 72057594042646528 (type In-row
data). 0 pages used in 0 dedicated extents.
Total number of extents is 0.
File 1. The number of extents = 25, used pages = 174, and reserved pages = 195.
?????????? File 1 (number of mixed extents = 18, mixed pages = 139).
??? Object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data),
data extents 1, pages 10, mixed extent pages 9.
??? Object ID 5, index ID 1, partition ID 327680, alloc unit ID 327680 (type In-row data),
data extents 0, pages 2, mixed extent pages 2.
??? Object ID 7, index ID 1, partition ID 458752, alloc unit ID 458752 (type In-row data),
data extents 0, pages 4, mixed extent pages 4.
??? Object ID 7, index ID 2, partition ID 562949953880064, alloc unit ID 562949953880064
(type In-row data), index extents 0, pages 2, mixed extent pages 2.

?? Object ID 2073058421, index ID 1, partition ID 72057594038386688, alloc unit ID
72057594042384384 (type In-row data), data extents 2, pages 23, mixed extent pages 9.
The total number of extents = 25, used pages = 174, and reserved pages = 195 in this
database.
?????? (number of mixed extents = 18, mixed pages = 139) in this database.
CHECKALLOC found 0 allocation errors and 0 consistency errors in database 'CorruptDB'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

?

關于DBCC CHECKALLOC的詳細用法，請看technet:
http://technet.microsoft.com/zh-cn/library/ms188422.aspx

?

■DBCC CHECKTABLE

DBCC CHECKTABLE執行如下操作：

◆? 原始系統目錄一致性檢查

◆? 在定義的單表上每表一致性檢查

◆? 在引用管些表的索引視圖上的交叉表一致性檢查

如果任何定義表中的破損被發現，交叉表一致性檢查不會被執行，即使破壞已經被修復。

此外，一個非聚集索引ID被定義為限制非聚集索引的交叉僅僅檢查非聚集索引。如果任何修復選項被使用，這不能被定義。

它使用默認的數據庫快照，與DBCC　CHECKED有相同的選項，包含修復。

該命令的輸出僅僅限定到被檢查的表。

關于DBCC CHECKTABLE的詳細用法，請看technet:?

http://technet.microsoft.com/zh-cn/library/ms174338.aspx

?

■DBCC CHECKFILEGROUP

DBCC CHECKFILEGROUP執行以下操作：

◆? 原始系統目錄一致性檢查

◆? 在存儲在文件組的所有表上的每表一致性檢查

◆? 交叉靜表一致性檢查，只要存儲在Fielgroup中的索引視圖、XML索引、空間索引和這些索引引用的表也被存儲在filegroup

它默認使用一個數據庫快照，與DBCC　CHECKED有相同的選項，除了以下：

◆? PHYSICAL_ONLY

◆? DATA_PURITY

◆? 任何修復選項

還有在每一個表時，表及其所有非聚集索引不存儲在同一文件組時，每表一致性檢查有以下微妙之處：

◆? 如果一個表被定義在文件組，但一個或多個非聚集索引存儲在其他文件組存儲，他們不被檢查一致性。

◆? 如果一個非聚集索引被存儲在定義的文件組，但表(Heap或聚集索引）被存儲在另一個文件組，非聚集索引不會被檢查一致性。

這個thumb的基本規則是DBCC CHECKFILEGROUP不執行交叉文件組一致性檢查。

這個命令的輸出與DBCC CHECKED相同，只不過它不輸出任何服務代理信息，并且僅僅在定義的文件組里的表被檢查。

關于DBCC CHECKFILEGROUP的詳細用法，請看MSDN:?

http://msdn.microsoft.com/en-us/library/ms187332.aspx

■DBCC CHECKCATALOG

DBCC CHECKCATALOG執行以下操作：

◆? 原始系統目錄一致性檢查

◆? 交叉目錄一致性檢查

它使用默認的數據庫快照，僅具有NO_INFOMSGS選項。如果數據庫無法創建快照，它需要一個獨占的數據庫鎖來運行。假定沒有一個數據庫快照，也沒有排他鎖可以在tempdb中獲得，則DBCC CHECKCATALOG不能運行在tempdb數據庫（無論是作為DBCC CHECKDB的一部分或作為獨立的命令）。

這個命令輸出為空，除非任何破損被找到。

關于DBCC CHECKCATALOG的詳細用法，請看MSDN:?

http://msdn.microsoft.com/en-us/library/ms186720.aspx

?

■DBCC CHECKIDENT

DBCC CHECKIDENT檢查所定義表的標識值是否有效，必要時自動重置。它通過掃描指定的表中的行以找到最高標識值，然后比較下一個存儲在表中的元數據標識值。

如果需要的話，該命令還可以用來手動重置標識值。應小心這樣做，以免產生意外地在標識列產生重復值。

如果該命令只檢查標識值，則該表被一個意向共享鎖(intent-shared)鎖定，對并發操作的影響極小。如果一個新值已被指定，該表已被架構修改鎖鎖定，以便于短時間內表的元數據修改，

?

關于DBCC CHECKIDENT的詳細用法，請看Thchnet:?

http://technet.microsoft.com/zh-cn/library/ms176057.aspx

?

■DBCC CHECKCONSTRAINTS

DBCC CHECKCONSTRAINTS會檢查已啟用的FOREIGN KEY和在數據庫中定義的CHECK約束。它可以檢查一個單一的約束，一個表上的所有約束，或在數據庫中的所有約束。如果ALL_CONSTRAINTS選項被指定，它還會檢查任何已停用的FOREIGN KEY和CHECK約束。

它的工作原理是通過創建一個查詢來查找所有違反約束的行。該查詢使用一個內部查詢提示，告知查詢處理器，DBCC CHECKCONSTRAINTS正在運行，它不應該縮短查詢，由于其現有約束的關系。

它不使用數據庫快照，而運行在任何會話的隔離級別設置。您必須設置會話選項CONCAT_NULL_YIELDS_NULL為ON，否則，該命令失敗，報錯誤2507。如果違反任何行約束，該行的鍵被輸出，并有一個包含行的表名和違反約束的名稱。

提示：DBCC CHECKCONSTRAINTS應該在執行各種DBCC修復后被運行，因為修復并不統計約束。

關于DBCC CHECKCONSTRAINTS的詳細用法，請看MSDN:?

http://msdn.microsoft.com/en-us/library/ms189496.aspx

?

小結：到此為止，SQL Server2008能在一個數據庫上執行的一致性檢查，與早期版本比較，已經非常全面，有了顯著的廣度，深度和效率。此外，你可以看到為什么DBCC CHECKDB會在一個大的、復雜的數據庫花很長的時間來完成。?

至此，數據庫一致性檢查及DBCC命令告一段落，本書也暫時到這兒，還有本書的一些遺漏部分，邀月會抽空補上，感謝大家的關注。

有興趣的朋友可以關注這個系列的目錄索引：
http://www.cnblogs.com/downmoon/archive/2010/01/26/1656411.html

總結

以上是生活随笔為你收集整理的《Microsoft Sql server 2008 Internals》读书笔记--第十一章DBCC Internals(11)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。