DBCC CHECKFILEGROUP (Transact-SQL)

项目
12/15/2008

更新日期： 2008 年 11 月 17 日

检查当前数据库中指定文件组中的所有表和索引视图的分配和结构完整性。

语法

DBCC CHECKFILEGROUP 
[
    [ ( { filegroup | filegroup_id | 0 } 
        [ , NOINDEX ] 
    ) ]
    [ WITH 
        { 
            [ ALL_ERRORMSGS | NO_INFOMSGS ] 
            [ , TABLOCK ] 
            [ , ESTIMATEONLY ]
            [ , PHYSICAL_ONLY ]  
        } 
    ]
]

参数

filegroup_name
当前数据库中要检查其表分配和结构完整性的文件组的名称。如果不指定此参数或指定了 0 值，则默认值为主文件组。文件组名称必须遵循有关标识符的规则。

filegroup_id
当前数据库中要检查其表分配和结构完整性的文件组标识 (ID) 号。

NOINDEX
指定不应对用户表的非聚集索引执行会占用很大系统开销的检查。这将减少总执行时间。NOINDEX 不影响系统表，因为 DBCC CHECKFILEGROUP 总是对所有系统表索引进行检查。

ALL_ERRORMSGS
显示每个对象不受限制的错误数。在 SQL Server 2005 Service Pack 3 (SP3) 中，默认情况下显示所有错误消息。指定或省略此选项都不起作用。在 SQL Server 的早期版本中，如果未指定 ALL_ERRORMSGS，则只为每个对象显示前 200 条错误消息。

NO_INFOMSGS
取消所有信息性消息。

TABLOCK
使 DBCC CHECKFILEGROUP 获取锁而不是使用内部数据库快照。

ESTIMATE ONLY
显示运行包含所有其他指定选项的 DBCC CHECKFILEGROUP 时所需的 tempdb 空间估计数量。

PHYSICAL_ONLY
限制为检查页、记录标头的物理结构以及 B 树物理结构的完整性。此选项旨在以较低的开销检查文件组的物理一致性，同时，此项检查还可以检测可能危及用户数据安全的残缺页和常见的硬件故障。DBCC CHECKFILEGROUP 完整运行的时间可能比早期版本要长得多。导致此行为发生的原因如下：
- 逻辑检查比较全面。
- 要检查的某些基础结构更为复杂。
- 引入了许多新的检查以包含新增功能。
因此，使用 PHYSICAL_ONLY 选项可能会使 DBCC CHECKFILEGROUP 在大型文件组上运行的时间短得多，所以对需要频繁检查的生产系统，建议使用 DBCC CHECKFILEGROUP。我们仍然建议定期执行 DBCC CHECKFILEGROUP 的完整运行。这些运行的执行频率取决于各业务和生产环境特定的因素。PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何修复选项一同使用。

注意指定 PHYSICAL_ONLY 会导致 DBCC CHECKFILEGROUP 跳过 FILESTREAM 数据的所有检查。

结果集

DBCC CHECKFILEGROUP 返回以下结果集（值可能有所不同）：

在指定了 ESTIMATEONLY 或 NO_INFOMSGS 时除外。
如果未指定数据库，则无论是否指定选项（NOINDEX 除外）都默认为当前数据库。

DBCC results for 'master'.
DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.
DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.

There are 2340 rows in 16 pages for object 'spt_values'.
DBCC results for 'MSreplication_options'.
There are 2 rows in 1 pages for object 'MSreplication_options'.
CHECKFILEGROUP found 0 allocation errors and 0 consistency errors in database 'master'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

如果指定了 NO_INFOMSGS，则 DBCC CHECKFILEGROUP 返回：

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

如果指定了 ESTIMATEONLY，则 DBCC CHECKFILEGROUP 返回（值可能有所不同）：

Estimated TEMPDB space needed for CHECKALLOC (KB) 
------------------------------------------------- 
15

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
207

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

备注

DBCC CHECKFILEGROUP 和 DBCC CHECKDB 是相似的 DBCC 命令。主要差异是 DBCC CHECKFILEGROUP 限于单个指定文件组和所需的表。

DBCC CHECKFILEGROUP 执行以下命令：

文件组的 DBCC CHECKALLOC。
文件组中的每个表和索引视图的 DBCC CHECKTABLE。

不要求将 DBCC CHECKALLOC 或 DBCC CHECKTABLE 与 DBCC CHECKFILEGROUP 分开运行。

内部数据库快照

DBCC CHECKFILEGROUP 使用内部数据库快照来提供执行这些检查所必需的事务一致性。有关详细信息，请参阅了解数据库快照中的稀疏文件大小和 DBCC (Transact-SQL) 中的“DBCC 内部数据库快照用法”部分。

如果无法创建快照，或指定了 TABLOCK 选项，则 DBCC CHECKFILEGROUP 会获取锁以获得所需的一致性。在这种情况下，需要排他数据库锁才能执行分配检查，需要共享表锁才能执行表检查。TABLOCK 可使 DBCC CHECKFILEGROUP 在负荷较重的数据库上运行得更快，但 DBCC CHECKFILEGROUP 运行时会降低数据库的可用并发性。

注意：
在 SQL Server 2005 中，对 tempdb 运行 DBCC CHECKFILEGROUP 不会执行任何分配检查，并且必须获取共享表锁才能执行表检查。这是因为，为了提高性能，不允许对 tempdb 使用数据库快照。这意味着无法获得所需的事务一致性。

并行检查对象

默认情况下，DBCC CHECKFILEGROUP 对对象执行并行检查。并行度由查询处理器自动确定。最大并行度的配置与配置并行查询相同。若要限制 DBCC 检查可使用的处理器的最大数目，请使用 sp_configure。有关详细信息，请参阅max degree of parallelism 选项。

通过使用跟踪标志 2528 可以禁用并行检查。有关详细信息，请参阅跟踪标志 (Transact-SQL)。

单独文件组的非聚集索引

如果指定文件组中的非聚集索引与其他文件组中的表关联，则不会检查该索引，因为不能验证基表。这是 SQL Server 2005 中的行为更改。在早期版本的 SQL Server 中，会检查其他文件组中的非聚集索引和基表。若要同时对非聚集索引和基表进行检查，请运行 DBCC CHECKDB。

如果指定文件组中的表在其他文件组中有非聚集索引，则在下列情况下，不检查非聚集索引：

基表结构依赖于非聚集索引的结构。不必扫描非聚集索引就可验证基表。
DBCC CHECKFILEGROUP 命令只对指定文件组中的对象进行验证。

聚集索引和表不能属于不同文件组；所以，前述注意事项仅适用于非聚集索引。

单独文件组上的已分区表

在 Service Pack 2 (SP2) 之前的 SQL Server 2005 版本中，仅当整个已分区表在指定文件组上时 DBCC CHECKFILEGROUP 才检查已分区表。如果表分布在多个文件组上，则将忽略整个表。在 SP2 中，当已分区表存在于多个文件组上时，DBCC CHECKFILEGROUP 将检查存在于指定文件组上的分区行集，并忽略其他文件组上的行集。信息性消息 2594 指出未检查的分区。不会检查未驻留在指定文件组上的非聚集索引。

了解 DBCC 错误消息

DBCC CHECKFILEGROUP 命令完成后，会将一条消息写入 SQL Server 错误日志。如果 DBCC 命令成功执行，则消息指示成功完成以及命令运行的时间。如果 DBCC 命令在完成检查之前由于错误而停止，则消息将指示命令已终止，并指示状态值和命令运行的时间。下表列出并说明了此消息中可包含的状态值。

状态	说明
0	引发了错误号 8930。这指示导致 DBCC 命令终止的元数据损坏。
1	出现错误号 8967。存在一个内部 DBCC 错误。
2	在紧急模式数据库修复过程中出错。
3	这指示导致 DBCC 命令终止的元数据损坏。
4	检测到断定或访问违规。
5	出现终止了 DBCC 命令的未知错误。

错误报告

在 SQL Server 2005 Service Pack 1 (SP1) 中，一旦 DBCC CHECKFILEGROUP 检测到破坏错误，就将在 SQL Server LOG 目录中创建微型转储文件 (SQLDUMPnnnn.txt)。如果为 SQL Server 实例启用了“功能使用情况数据收集”和“错误报告”功能，该文件将被自动转发给 Microsoft。收集的数据将用于改进 SQL Server 功能。有关详细信息，请参阅错误和使用情况报告设置。

转储文件包含 DBCC CHECKFILEGROUP 命令的结果以及其他诊断输出数据。该文件拥有任意访问控制列表 (DACL)。只有 SQL Server 服务帐户和 sysadmin 角色的成员有权进行访问。默认情况下，sysadmin 角色包含 Windows BUILTIN\Administrators 组和本地管理员组的所有成员。如果数据收集进程失败，DBCC 命令不会失败。

纠正错误

如果 DBCC CHECKFILEGROUP 报告了错误，建议使用数据库备份还原数据库。请注意，不能将修复操作指定为 DBCC CHECKFILEGROUP。

如果不存在备份，请运行包含指定修复选项的 DBCC CHECKDB 来更正报告的错误。如果报告了错误，则在列表末尾指定要使用的修复选项。使用 REPAIR_ALLOW_DATA_LOSS 选项更正错误可能需要删除部分页，从而会删除部分数据。

权限

要求具有 sysadmin 固定服务器角色或 db_owner 固定数据库角色的成员身份。

示例

A. 检查 AdventureWorks 数据库中的 PRIMARY 文件组

以下示例将检查 AdventureWorks 数据库主文件组。

USE AdventureWorks;
GO
DBCC CHECKFILEGROUP;
GO

B. 检查不含非聚集索引的 AdventureWorks PRIMARY 文件组

以下示例通过指定主文件组的标识号并指定 NOINDEX，对 AdventureWorks 数据库主文件组（不包括非聚集索引）进行检查。

USE AdventureWorks;
GO
DBCC CHECKFILEGROUP (1, NOINDEX);
GO

C. 检查带有选项的 PRIMARY 主文件组

以下示例将检查 master 数据库主文件组并指定选项 ESTIMATEONLY。

USE master;
GO
DBCC CHECKFILEGROUP (1)
WITH ESTIMATEONLY;

请参阅

更改历史记录

版本	历史记录
2008 年 11 月 17 日	新增内容： ALL_ERRORMSGS 的定义中介绍了 SP3 中的新增功能。
2006 年 12 月 12 日	新增内容：在“备注”部分中，添加了“单独文件组上的已分区表”小节。此部分描述了 SP2 中的新功能。
2006 年 4 月 14 日	新增内容：在“备注”部分中，添加了“错误报告”子部分。此部分描述了 SP1 中的新功能。
2005 年 12 月 5 日	新增内容：添加了示例 C。更改的内容：更正了语法。向“备注”部分添加了有关写入 SQL Server 错误日志的消息的有关信息以及状态值的说明。针对单独文件组的非聚集索引更改了“备注”部分以反映 SQL Server 2005 行为。

通过