《Microsoft Sql server 2008 Internals》读书笔记--第十一章DBCC Internals(11)
《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