《Microsoft Sql server 2008 Internals》读书笔记--第十一章DBCC Internals(9)

《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 CHECKED输出

DBCC CHECKED用四种方式输出信息：

◆常规输出，由一个错误的信息和邮件组成的列表指向发布DBCC CHECKDB命令的连接。

◆SQL Server 错误日志的一条信息

◆Windows 应用程序事件日志的一个项。

◆在sys.dm_exec_requests目录视图的进度报告信息

■常规输出

默认，DBCC CHECKED输出如下：
 ◆服务代理一致性检查的概要

◆分配错误的列表，加这些错误的计数

◆影响到表的地方不能被确定的错误列表，加这些错误的计数

◆对于每一个数据库中的（包括系统目录表）：

行数和页数

错误列表及错误的计数。

◆分配和一致性错误的概要计数

◆必须被定义以修复已报告错误的最小修复级别

DBCC　CHECKED输出的一个例子如下：（数据库包含一些破损）:

DBCC results for 'CorruptDB'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page
ID (1:158) contains an incorrect page ID in its page header. The PageId in the page header =
(0:0).
CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single
object.
DBCC results for 'sys.sysrscols'.
There are 637 rows in 8 pages for object "sys.sysrscols".
DBCC results for 'sys.sysrowsets'.
There are 92 rows in 1 pages for object "sys.sysrowsets".
DBCC results for 'sys.sysallocunits'.
There are 104 rows in 2 pages for object "sys.sysallocunits".
DBCC results for 'sys.sysfiles1'.
There are 2 rows in 1 pages for object "sys.sysfiles1".
DBCC results for 'sys.syspriorities'.
There are 0 rows in 0 pages for object "sys.syspriorities".
DBCC results for 'sys.sysfgfrag'.

There are 2 rows in 1 pages for object "sys.sysfgfrag".
<some results removed for brevity>
DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".
DBCC results for 'sys.sysbinsubobjs'.
There are 3 rows in 1 pages for object "sys.sysbinsubobjs".
DBCC results for 'sys.syssoftobjrefs'.
There are 0 rows in 0 pages for object "sys.syssoftobjrefs".
DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
DBCC results for 'sales'.
Msg 8928, Level 16, State 1, Line 1
Object ID 2073058421, index ID 1, partition ID 72057594038386688, alloc unit ID
72057594042384384 (type In-row data): Page (1:158) could not be processed.  See other errors
for details.
There are 4755 rows in 20 pages for object "sales".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sales' (object ID
2073058421).
DBCC results for 'sys.filestream_tombstone_2121058592'.
There are 0 rows in 0 pages for object "sys.filestream_tombstone_2121058592".
DBCC results for 'sys.syscommittab'.
There are 0 rows in 0 pages for object "sys.syscommittab".
CHECKDB found 0 allocation errors and 2 consistency errors in database 'CorruptDB'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB
(CorruptDB).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

虽然这个输出是全面的，但消息是冗余的。在正常操作中，涉及破损的重要信息可能会在数据库中。总是建议使用NO_INFOMSGS选项，以减少输出，仅仅必要的信息。例如，这里是来自相同的破损数据库的DBCC　CHECKDB输出，但NO_INFOMSGS选项被定义：

Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page
ID (1:158) contains an incorrect page ID in its page header. The PageId in the page header =
(0:0).
CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single
object.
Msg 8928, Level 16, State 1, Line 1
Object ID 2073058421, index ID 1, partition ID 72057594038386688, alloc unit ID
72057594042384384 (type In-row data): Page (1:158) could not be processed.  See other errors
for details.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sales' (object ID
2073058421).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'CorruptDB'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB
(CorruptDB).

正如你所看到，这个输出信息易读性不错。

当DBCC CHECKED被在master数据库中执行是一个特例。此时，DBCC CHECKED也被运行在隐藏的资源数据库mssqlsystemresource,因此输出结果中包含这两个数据库的结果。

如果DBCC CHECKDB因为某种原因提前终止，不能被DBCC CHECKDB控制，错误5235输出，包含一个错误状态。错误状态具有以下含义：

◆０  一个致命的元数据破损被检测到。一个或更多的8930错误，伴随着5235错误。

◆１  一个无效的内部状态在DBCC CHECKED内部被检测到。一个或更多的8967错误，伴随着5235错误。

◆２  对关键系统表中的原始检查失败。一个或更多的7984到7988错误，伴随着5235错误。

◆３  合并模式因为数据库不能在重建事务日志后不能重启而修复失败。7909错误，伴随着5235错误。

◆４  一个访问冲突或断言发生（即使DBCC CHECKED已经在SQL Server2005中被重新设计以避免这些错误发生）

◆５  一个未知原因引起DBCC CHECKED终止，尽管也可能是graceful.

在SQL Server2008中，任何时候被ＤBCC CHECKED发现的错误，一个故障文件在实例日志目录被创建，还有一些ＸＭＬ格式的错误的文本概要和一个当前SQL Server错误日志文件的副本。如果实例被配置为提供反馈给microsoft，这些文件会被自动上传。

 

■SQL Server错误日志输出

每次DBCC CHECKED成功完成时，一个关于被一致性检查的数据库的项被加到SQL Server错误日志。一个错误例子如下：
2008-11-03 00:51:11.08 spid56      DBCC CHECKDB (CorruptDB) executed by CHICAGO\
Administrator found 2 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0
seconds.  Internal database snapshot has split point LSN = 00000044:00000188:0001 and first
LSN = 00000044:00000187:0001.  This is an informational message only. No user action is
required. 

请注意该项(entry)列出DBCC CHECKDB完成的elapsed时间。这可以使数据库管理员可以获得一些必要的判断信息，而不必为特定的数据库诉诸人工计时DBCC CHECKDB的平均运行时间。该项还列出了哪个选项被定义。这对于决定数据库以前是否被修复可能是有用的。
该项还列出了DBCC CHECKDB创建的一些有关数据库快照的元数据信息。这对产品支持调试时的破损问题可能是有用的。

如果DBCC CHECKDB过早终止，一个简单型的项(entry)在错误日志中被输入。如果在存储引擎的高危险性的错误导致DBCC CHECKDB无法控制地终止，项不会出现在错误日志中。该错误日志项的生成是DBCC CHECKDB完成时所做的最后的事情之一。这意味着，如果发生错误，例如，终止运行命令的连接，DBCC CHECKDB无法生成错误日志项。

■应用程序事件日志输出

DBCC CHECKED在每次写输出到SQL Server错误日志时生成一个匹配的应用程序事件日志。

每次DBCC CHECKED成功完成时，一个项被加到应用程序事件日志标明错误被发现我修复的序号，一个例子如下：

如果错误被DBCC CHECKED发现，在包含错误报告的故障文件的元数据的事件日志中可能有三个附加的项。
 在DBCC CHECKED决定提前终止的事件中，一个简单的项输入到事件日志。如果SQL Server错误日志项没被生成，那是因为DBCC CHECKED不受控制地终止，应用程序事件日志项也不生成。

■进度报告输出

DBCC CHECKED，DBCC CHECKTABLE，DBCC CHECKFILEGROUP都在sys.dm_exec_requests目录视图中报告它们的进度。相关的两个列是percent_complete(自我解释)和command（当前DBCC命令被执行的执行阶段），下表展示了执行的顺序：

 

注意：并没有针对原始的系统表检查的阶段被报告。这个阶段运行得很快以至于在SQL Server　2005中的进度报告被加到DBCC　CHECKED时，开发小组不认为有必要包括一个隔离的进度报告阶段。
对于DBCC CHECKTABLE，下列阶段被报告：

◆DBCC　TABLE　CHECK

◆DBCC　IVIEW　CHECK（如果上一步未发现错误）

◆DBCC　TABLE　REPAIR（如果发现一个错误，并且一个修复选项被定义）

对于DBCC CHECKFILEGROUP，下列阶段被报告：

◆DBCC　ALLOC　CHECK

◆DBCC SYS CHECK

◆DBCC TABLE CHECK
 注意：DBCC CHECKFILEGROUP不支持修复操作。

下篇将关注DBCC CHECKDB选项