DBCC CHECKFILEGROUP (Transact-SQL)

更新： 2008 年 11 月 17 日

檢查目前資料庫之指定檔案群組中所有資料表和索引檢視表的配置和結構完整性。

Transact-SQL 語法慣例

語法

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。這些執行動作的頻率取決於個別商務和實際執行環境特有的因素。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 CHECKFILEGROUP 之外，個別執行 DBCC CHECKALLOC 或 DBCC CHECKTABLE。

內部資料庫快照集

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 命令由於發生錯誤而在完成檢查之前停止執行，則訊息中會指出命令已經終止，並顯示狀態值以及命令執行的時間量。下表列出並描述可以包含在訊息中的狀態值。

錯誤報告

在 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;

請參閱

參考

DBCC (Transact-SQL)
FILEGROUP_ID (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)
sys.sysfilegroups (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
DBCC CHECKALLOC (Transact-SQL)
DBCC CHECKTABLE (Transact-SQL)

其他資源

實體資料庫架構

說明及資訊

取得 SQL Server 2005 協助

變更歷程記錄