《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