DBCC CHECKDB (Transact-SQL)DBCC CHECKDB (Transact-SQL)

本主題適用於:是SQL Server (從 2012 開始)是Azure SQL Database否Azure SQL 資料倉儲 否平行處理資料倉儲 THIS TOPIC APPLIES TO:yesSQL Server (starting with 2012)yesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

藉由執行下列作業,檢查指定資料庫中所有物件的邏輯完整性和實體完整性:Checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

注意: DBCC CHECKDB 的資料庫包含記憶體最佳化資料表支援,但是驗證只會發生以磁碟為基礎的資料表上。NOTE: DBCC CHECKDB is supported on databases that contain memory-optimized tables but validation only occurs on disk-based tables. 不過,在資料庫備份和復原的過程中,會針對記憶體最佳化檔案群組中的檔案執行 CHECKSUM 驗證。However, as part of database backup and recovery, a CHECKSUM validation is done for files in memory-optimized filegroups.

因為 DBCC 修復選項無法用於記憶體最佳化資料表,所以您必須定期備份資料庫,並測試備份。Since DBCC repair options are not available for memory-optimized tables, you must back up your databases regularly and test the backups. 如果記憶體最佳化資料表中發生資料完整性問題,您必須從最後已知的良好備份還原。If data integrity issues occur in a memory-optimized table, you must restore from the last known good backup.

  • 執行DBCC CHECKALLOC在資料庫上。Runs DBCC CHECKALLOC on the database.

  • 執行DBCC CHECKTABLE上每個資料表和檢視資料庫中的。Runs DBCC CHECKTABLE on every table and view in the database.

  • 執行DBCC CHECKCATALOG在資料庫上。Runs DBCC CHECKCATALOG on the database.

  • 驗證資料庫中每一索引檢視的內容。Validates the contents of every indexed view in the database.

  • 儲存時,會驗證資料表中繼資料和檔案系統目錄和檔案之間的連結層級一致性varbinary (max)使用 FILESTREAM 的檔案系統中的資料。Validates link-level consistency between table metadata and file system directories and files when storing varbinary(max) data in the file system using FILESTREAM.

  • 驗證資料庫中的 Service BrokerService Broker 資料。Validates the Service BrokerService Broker data in the database.

    這表示 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG 命令不需要與 DBCC CHECKDB 分開獨立執行。This means that the DBCC CHECKALLOC, DBCC CHECKTABLE, or DBCC CHECKCATALOG commands do not have to be run separately from DBCC CHECKDB. 如需有關這些命令執行之檢查的詳細資訊,請參閱這些命令的描述。For more detailed information about the checks that these commands perform, see the descriptions of these commands.

    主題連結圖示 Transact-SQL 語法慣例Topic link icon Transact-SQL Syntax Conventions

語法Syntax


DBCC CHECKDB     
    [ ( database_name | database_id | 0    
        [ , NOINDEX     
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]    
    ) ]    
    [ WITH     
        {    
            [ ALL_ERRORMSGS ]    
            [ , EXTENDED_LOGICAL_CHECKS ]     
            [ , NO_INFOMSGS ]    
            [ , TABLOCK ]    
            [ , ESTIMATEONLY ]    
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]    
            [ , MAXDOP  = number_of_processors ]    
        }    
    ]    
]    

引數Arguments

database_name | database_id | 0database_name | database_id | 0
這是要執行完整性檢查的資料庫識別碼或名稱。Is the name or ID of the database for which to run integrity checks. 若未指定,或指定 0,就會使用目前的資料庫。If not specified, or if 0 is specified, the current database is used. 資料庫名稱必須符合的規則識別碼Database names must comply with the rules for identifiers.

NOINDEXNOINDEX
指定不應該執行使用者資料表之非叢集索引的大量檢查。Specifies that intensive checks of nonclustered indexes for user tables should not be performed. 這會減少整體的執行時間。This decreases the overall execution time. NOINDEX 不會影響系統資料表,因為系統資料表索引一律會執行完整性檢查。NOINDEX does not affect system tables because integrity checks are always performed on system table indexes.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILDREPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKDB 修復發現的錯誤。Specifies that DBCC CHECKDB repair the found errors. 最好不要使用這些 REPAIR 選項。Use the REPAIR options only as a last resort. 指定的資料庫必須為單一使用者模式,才能使用下列修復選項之一。The specified database must be in single-user mode to use one of the following repair options.

REPAIR_ALLOW_DATA_LOSSREPAIR_ALLOW_DATA_LOSS
嘗試修復所有報告的錯誤。Tries to repair all reported errors. 這些修復可能會造成某些資料的遺失。These repairs can cause some data loss.

警告

  • REPAIR_ALLOW_DATA_LOSS 選項是支援的功能,但它可能永遠無法將資料庫帶到實體一致的狀態的最佳選項。The REPAIR_ALLOW_DATA_LOSS option is a supported feature but it may not always be the best option for bringing a database to a physically consistent state. -如果成功的話,REPAIR_ALLOW_DATA_LOSS 選項可能會導致部分資料遺失。-If successful, the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. 事實上,這個選項遺失的資料,可能會比使用者從上次已知良好備份還原資料庫所遺失的資料多。In fact, it may result in more data lost than if a user were to restore the database from the last known good backup.

  • MicrosoftMicrosoft 一律建議使用者從上次已知良好的備份還原,做為修復 DBCC CHECKDB 所報告之錯誤的主要方法。 always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. REPAIR_ALLOW_DATA_LOSS 選項無法取代從已知良好的備份還原方法。The REPAIR_ALLOW_DATA_LOSS option is not an alternative for restoring from a known good backup. 只有在不可能從備份還原時,才建議使用這個「上次還原」緊急選項。It is an emergency “last resort” option recommended for use only if restoring from a backup is not possible.

    • 某些只能透過 REPAIR_ALLOW_DATA_LOSS 選項修復的錯誤,可能需要取消配置資料列、頁面或一系列頁面,才能清除錯誤。Certain errors, that can only be repaired using the REPAIR_ALLOW_DATA_LOSS option, may involve deallocating a row, page, or series of pages to clear the errors. 使用者將無法再存取或復原任何已取消配置的資料,也無法判斷其確切內容。Any deallocated data is no longer accessible or recoverable for the user, and the exact contents of the deallocated data cannot be determined. 因此,取消配置任何資料列或頁面之後,參考完整性可能會不正確,因為在這項修復作業期間不會檢查或維護外部索引鍵條件約束。Therefore, referential integrity may not be accurate after any rows or pages are deallocated because foreign key constraints are not checked or maintained as part of this repair operation. 使用者在使用 REPAIR_ALLOW_DATA_LOSS 選項之後,必須檢查其資料庫的參考完整性 (使用 DBCC CHECKCONSTRAINTS)。The user must inspect the referential integrity of their database (using DBCC CHECKCONSTRAINTS) after using the REPAIR_ALLOW_DATA_LOSS option.

    • 在執行修復之前,請建立屬於這個資料庫的檔案實體複本。Before performing the repair, create physical copies of the files that belong to this database. 這包括主要資料檔 (.mdf)、任何次要資料檔 (.ndf)、所有交易記錄檔 (.ldf) 以及其他構成資料庫的容器,包括全文檢索目錄、檔案資料流資料夾、記憶體最佳化的資料等。This includes the primary data file (.mdf), any secondary data files (.ndf), all transaction log files (.ldf), and other containers that form the database including full text catalogs, file stream folders, memory optimized data, etc.

    • 在執行修復之前,請考慮將資料庫的狀態變更為「緊急」模式,並嘗試從關鍵資料表中擷取盡可能最多的資訊,然後儲存該資料。Before performing the repair, consider changing the state of the database to EMERGENCY mode and trying to extract as much information possible from the critical tables and save that data.

REPAIR_FASTREPAIR_FAST
維護這個語法的目的,只是為了與舊版相容。Maintains syntax for backward compatibility only. 不會執行任何修復動作。No repair actions are performed.

REPAIR_REBUILDREPAIR_REBUILD
執行不可能造成資料遺失的修復,Performs repairs that have no possibility of data loss. 這可包括快速修復 (例如,修復非叢集索引中遺失的資料列) 以及更耗時的修復 (例如,重建索引)。This can include quick repairs, such as repairing missing rows in non-clustered indexes, and more time-consuming repairs, such as rebuilding an index.
這個引數不會修復與 FILESTREAM 資料有關的錯誤。This argument does not repair errors involving FILESTREAM data.

重要

由於搭配任何 REPAIR 選項的 DBCC CHECKDB 已完整記錄下來並可復原,因此 MicrosoftMicrosoft 一律會建議使用者在交易內 (執行命令前先執行 BEGIN TRANSACTION) 搭配任何 REPAIR 選項使用 CHECKDB,以便使用者可以確認要接受作業的結果。Since DBCC CHECKDB with any of the REPAIR options are completely logged and recoverable, MicrosoftMicrosoft always recommends a user use CHECKDB with any REPAIR options within a transaction (execute BEGIN TRANSACTION before running the command) so that the user can confirm he/she wants to accept the results of the operation. 接著使用者可執行 COMMIT TRANSACTION,來認可修復作業完成的所有工作。Then the user can execute COMMIT TRANSACTION to commit all work done by the repair operation. 如果使用者不想接受作業的結果,可執行 ROLLBACK TRANSACTION 恢復修復作業的結果。If the user does not want to accept the results of the operation, he/she can execute a ROLLBACK TRANSACTION to undo the effects of the repair operations.

若要修復錯誤,我們建議您從備份中還原。To repair errors, we recommend restoring from a backup. 修復作業並不考慮資料表或資料表之間的任何條件約束。Repair operations do not consider any of the constraints that may exist on or between tables. 如果指定的資料表涉及一或多項條件約束,建議您在修復作業之後,執行 DBCC CHECKCONSTRAINTS。If the specified table is involved in one or more constraints, we recommend running DBCC CHECKCONSTRAINTS after a repair operation. 如果您必須使用 REPAIR,請執行不含修復選項的 DBCC CHECKDB 來尋找要使用的修復層級。If you must use REPAIR, run DBCC CHECKDB without a repair option to find the repair level to use. 如果您使用 REPAIR_ALLOW_DATA_LOSS 層級,建議您在搭配這個選項執行 DBCC CHECKDB 之前,先備份資料庫。If you use the REPAIR_ALLOW_DATA_LOSS level, we recommend that you back up the database before you run DBCC CHECKDB with this option.

ALL_ERRORMSGSALL_ERRORMSGS
根據每個物件顯示所有報告的錯誤。Displays all reported errors per object. 系統預設會顯示所有錯誤訊息。All error messages are displayed by default. 指定或省略這個選項沒有任何作用。Specifying or omitting this option has no effect. 錯誤訊息會依照物件識別碼,從產生的訊息除外tempdb 資料庫Error messages are sorted by object ID, except for those messages generated from tempdb database.

注意

Transact-SQLSQL Server Management Studio 中,傳回的最大錯誤訊息數目是 1000。In Transact-SQLSQL Server Management Studio, the maximum number of error messages returned is 1000. 當您指定 ALL_ERRORMSGS 時,我們建議您藉由執行 DBCC 命令sqlcmd 公用程式或藉由排程 SQL ServerSQL Server代理程式作業來執行命令,並將輸出導向至檔案。When you specify ALL_ERRORMSGS, we recommend that you run the DBCC command by using the sqlcmd utility or by scheduling a SQL ServerSQL Server Agent job to run the command and direct the output to a file. 執行任何其中一種方式,都可確保執行一次命令將能回報所有錯誤訊息。Either of these methods will ensure that running the command once will report all error messages.

EXTENDED_LOGICAL_CHECKSEXTENDED_LOGICAL_CHECKS
如果相容性層級為 100 ( SQL Server 2008SQL Server 2008) 或更高,則會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯一致性檢查。If the compatibility level is 100 ( SQL Server 2008SQL Server 2008) or higher, performs logical consistency checks on an indexed view, XML indexes, and spatial indexes, where present.
如需詳細資訊,請參閱本主題稍後「備註」一節中的「對索引執行邏輯一致性檢查」。For more information, see "Performing Logical Consistency Checks on Indexes," in the "Remarks" section later in this topic.

NO_INFOMSGSNO_INFOMSGS
隱藏所有參考訊息。Suppresses all informational messages.

TABLOCKTABLOCK
使 DBCC CHECKDB 取得鎖定,而不使用內部資料庫快照集。Causes DBCC CHECKDB to obtain locks instead of using an internal database snapshot. 這包括資料庫上的短期獨佔 (X) 鎖定。This includes a short-term exclusive (X) lock on the database. TABLOCK 可讓 DBCC CHECKDB 在負載沉重的資料庫上執行得快一些,但 DBCC CHECKDB 執行時,資料庫可用的並行會降低。TABLOCK will cause DBCC CHECKDB to run faster on a database under heavy load, but decreases the concurrency available on the database while DBCC CHECKDB is running.

重要

TABLOCK 會限制執行的檢查;不會對資料庫執行 DBCC CHECKCATALOG,也不會驗證 Service BrokerService Broker 資料。TABLOCK limits the checks that are performed; DBCC CHECKCATALOG is not run on the database, and Service BrokerService Broker data is not validated.

ESTIMATEONLYESTIMATEONLY
顯示所需的所有其他指定選項執行 DBCC CHECKDB 的 tempdb 空間估計的量。Displays the estimated amount of tempdb space that is required to run DBCC CHECKDB with all the other specified options. 不會執行實際的資料庫檢查。The actual database check is not performed.

PHYSICAL_ONLYPHYSICAL_ONLY
將檢查限制於頁面實體結構、記錄標頭的完整性,以及資料庫配置的一致性。Limits the checking to the integrity of the physical structure of the page and record headers and the allocation consistency of the database. 這是設計來對資料庫實體一致性提供少量負擔檢查,這項檢查還能偵測到可能危及使用者資料的損毀頁、總和檢查碼失敗以及常見的硬體錯誤。This check is designed to provide a small overhead check of the physical consistency of the database, but it can also detect torn pages, checksum failures, and common hardware failures that can compromise a user's data.
完整執行 DBCC CHECKDB 所需要的完成時間可能比舊版長許多。A full run of DBCC CHECKDB may take considerably longer to complete than earlier versions. 此行為的發生狀況如下:This behavior occurs because:

  • 邏輯檢查更完整。The logical checks are more comprehensive.
  • 部分要檢查的基礎結構更複雜。Some of the underlying structures to be checked are more complex.
  • 導入了許多新的檢查,以包含新的功能。Many new checks have been introduced to include the new features.
    因此,使用 PHYSICAL_ONLY 選項可能使 DBCC CHECKDB 對大型資料庫的執行階段縮短許多,因此,建議您在實際系統上經常使用它。Therefore, using the PHYSICAL_ONLY option may cause a much shorter run-time for DBCC CHECKDB on large databases and is recommended for frequent use on production systems. 我們仍建議您定期完整執行 DBCC CHECKDB。We still recommend that a full run of DBCC CHECKDB be performed periodically. 這些執行動作的頻率取決於個別商務和實際執行環境特有的因素。The frequency of these runs depends on factors specific to individual businesses and production environments.
    此 argment 一律隱含 NO_INFOMSGS,且不允許使用任何一種修復選項。This argment always implies NO_INFOMSGS and is not allowed with any one of the repair options.

警告

指定 PHYSICAL_ONLY 會造成 DBCC CHECKDB 略過 FILESTREAM 資料的所有檢查。Specifying PHYSICAL_ONLY causes DBCC CHECKDB to skip all checks of FILESTREAM data.

DATA_PURITYDATA_PURITY
使 DBCC CHECKDB 檢查資料庫,找出無效或超出範圍的資料行值。Causes DBCC CHECKDB to check the database for column values that are not valid or out-of-range. 例如,DBCC CHECKDB 偵測到大於或小於的可接受範圍的日期和時間值的資料行datetime資料類型,或十進位或近似數值資料類型具有無效的小數位數或有效位數值的資料行。For example, DBCC CHECKDB detects columns with date and time values that are larger than or less than the acceptable range for the datetime data type; or decimal or approximate-numeric data type columns with scale or precision values that are not valid.
預設會啟用資料行值的完整性檢查,而不需要 DATA_PURITY 選項。Column-value integrity checks are enabled by default and do not require the DATA_PURITY option. 對於從舊版 SQL ServerSQL Server 升級的資料庫,在毫無錯誤的情況下完成對資料庫執行 DBCC CHECKDB WITH DATA_PURITY 之前,依預設不啟用資料行值的完整性檢查。For databases upgraded from earlier versions of SQL ServerSQL Server, column-value checks are not enabled by default until DBCC CHECKDB WITH DATA_PURITY has been run error free on the database. 此後,依預設 DBCC CHECKDB 會檢查資料行值的完整性。After this, DBCC CHECKDB checks column-value integrity by default. 如需有關從舊版 SQL ServerSQL Server 升級資料庫可能對 CHECKDB 造成何種影響的詳細資訊,請參閱本主題稍後的「備註」一節。For more information about how CHECKDB might be affected by upgrading database from earlier versions of SQL ServerSQL Server, see the Remarks section later in this topic.

警告

如果指定 PHYSICAL_ONLY,則不會執行資料行完整性檢查。If PHYSICAL_ONLY is specified, column-integrity checks are not performed.

這個選項報告的驗證錯誤無法使用 DBCC 修復選項更正。Validation errors reported by this option cannot be fixed by using DBCC repair options. 有關手動更正這些錯誤的詳細資訊,請參閱知識庫文件 923247: SQL Server 2005 和更新版本中的疑難排解 DBCC 錯誤 2570年For information about manually correcting these errors, see Knowledge Base article 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.

MAXDOPMAXDOP
適用於: SQL Server 2014SQL Server 2014 SP2 至 SQL Server 2017SQL Server 2017Applies to: SQL Server 2014SQL Server 2014 SP2 through SQL Server 2017SQL Server 2017.

覆寫的最大平行處理原則程度組態選項的sp_configure陳述式。Overrides the max degree of parallelism configuration option of sp_configure for the statement. MAXDOP 可以超過使用 sp_configure 所設定的值。The MAXDOP can exceed the value configured with sp_configure. 如果 MAXDOP 超過使用資源管理員所設定的值SQL Server Database EngineSQL Server Database Engine使用資源管理員 MAXDOP 值中所述ALTER WORKLOAD GROUPIf MAXDOP exceeds the value configured with Resource Governor, the SQL Server Database EngineSQL Server Database Engine uses the Resource Governor MAXDOP value, described in ALTER WORKLOAD GROUP. 當您使用 MAXDOP 查詢提示時,適用所有搭配 max degree of parallelism 組態選項使用的語意規則。All semantic rules used with the max degree of parallelism configuration option are applicable when you use the MAXDOP query hint. 如需詳細資訊,請參閱 設定 max degree of parallelism 伺服器組態選項For more information, see Configure the max degree of parallelism Server Configuration Option.

警告

如果 MAXDOP 設定為零,SQL Server 會選擇要使用的平行處理原則的最大程度。If MAXDOP is set to zero then SQL Server chooses the max degree of parallelism to use.

備註Remarks

DBCC CHECKDB 不會檢查停用的索引。DBCC CHECKDB does not examine disabled indexes. 如需已停用索引的詳細資訊,請參閱停用索引和條件約束For more information about disabled indexes, see Disable Indexes and Constraints. 如果使用者定義型別標示為按位元組排序,該使用者定義型別只能有一個序列。If a user-defined type is marked as being byte ordered, there must only be one serialization of the user-defined type. 按位元組排序之使用者定義型別如果沒有一致的序列,DBCC CHECKDB 執行期間將會發生錯誤 2537。Not having a consistent serialization of byte-ordered user-defined types causes error 2537 when DBCC CHECKDB is run. 如需詳細資訊,請參閱使用者定義型別需求For more information, see User-Defined Type Requirements. 因為Resource 資料庫只在單一使用者模式中,命令不能是直接在其上執行的 DBCC CHECKDB 可修改。Because the Resource database is modifiable only in single-user mode, the DBCC CHECKDB command cannot be run on it directly. 不過,當執行 DBCC CHECKDB 對master 資料庫,Resource 資料庫也在內部執行第二個 CHECKDB。However, when DBCC CHECKDB is executed against the master database, a second CHECKDB is also run internally on the Resource database. 這表示 DBCC CHECKDB 可能會傳回額外的結果。This means that DBCC CHECKDB can return extra results. 這個命令在未設定選項或僅設定 PHYSICAL_ONLY 或 ESTIMATEONLY 選項其中之一時,會傳回額外的結果集。The command returns extra result sets when no options are set, or when either the PHYSICAL_ONLY or ESTIMATEONLY option is set. 在 SP2 之前的 SQL Server 2005SQL Server 2005 版本中,執行 DBCC CHECKDB 會清除 SQL ServerSQL Server 執行個體的計畫快取。In versions of SQL Server 2005SQL Server 2005 before SP2, executing DBCC CHECKDB clears the plan cache for the instance of SQL ServerSQL Server. 清除計畫快取會導致重新編譯所有後續執行計畫,而且可能會導致查詢效能突然暫時下降。Clearing the plan cache causes recompilation of all later execution plans and may cause a sudden, temporary decrease in query performance. 在 SP2 及更新版本中,執行 DBCC CHECKDB 不會清除計畫快取。In SP2 and later, executing DBCC CHECKDB does not clear the plan cache.

對索引執行邏輯一致性檢查Performing Logical Consistency Checks on Indexes

對索引進行的邏輯一致性檢查會根據資料庫的相容性層級而異,如下所示:Logical consistency checking on indexes varies according to the compatibility level of the database, as follows:

  • 如果相容性層級為 100 ( SQL Server 2008SQL Server 2008) 或更高:If the compatibility level is 100 ( SQL Server 2008SQL Server 2008) or higher:
  • 除非指定了 NOINDEX,否則 DBCC CHECKDB 會針對單一資料表及它的所有非叢集索引進行實體和邏輯一致性檢查。Unless NOINDEX is specified, DBCC CHECKDB performs both physical and logical consistency checks on a single table and on all its nonclustered indexes. 但是根據預設,XML 索引、空間索引和索引檢視表只會進行實體一致性檢查。However, on XML indexes, spatial indexes, and indexed views only physical consistency checks are performed by default.
  • 如果指定了 WITH EXTENDED_LOGICAL_CHECKS,將會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯檢查。If WITH EXTENDED_LOGICAL_CHECKS is specified, logical checks are performed on an indexed view, XML indexes, and spatial indexes, where present. 根據預設,實體一致性檢查會在邏輯一致性檢查之前執行。By default, physical consistency checks are performed before the logical consistency checks. 如果也指定了 NOINDEX,則只會執行邏輯檢查。If NOINDEX is also specified, only the logical checks are performed.

這些邏輯一致性檢查會交叉檢查索引物件的內部索引資料表 (其中包含它所參考的使用者資料表)。These logical consistency checks cross check the internal index table of the index object with the user table that it is referencing. 若要尋找外圍的資料列,則會建構內部查詢來執行內部和使用者資料表的完整交集。To find outlying rows, an internal query is constructed to perform a full intersection of the internal and user tables. 執行這個查詢對於效能會有極大的影響,而且無法追蹤其進度。Running this query can have a very high effect on performance, and its progress cannot be tracked. 因此,只有當您懷疑發生了與實體損毀無關的索引問題,或是頁面層級總和檢查碼已經關閉,而且您懷疑發生了資料行層級的硬體損毀時,才建議您指定 WITH EXTENDED_LOGICAL_CHECKS。Therefore, we recommend that you specify WITH EXTENDED_LOGICAL_CHECKS only if you suspect index issues that are unrelated to physical corruption, or if page-level checksums have been turned off and you suspect column-level hardware corruption.

  • 如果此索引為已篩選的索引,DBCC CHECKDB 會執行一致性檢查,以確認索引項目可滿足篩選述詞。If the index is a filtered index, DBCC CHECKDB performs consistency checks to verify that the index entries satisfy the filter predicate.
  • 如果相容性層級為 90 以下,則除非指定了 NOINDEX,否則 DBCC CHECKDB 會針對單一資料表或索引檢視表及它的所有非叢集索引和 XML 索引進行實體和邏輯一致性檢查。If the compatibility level is 90 or less, unless NOINDEX is specified, DBCC CHECKDB performs both physical and logical consistency checks on a single table or indexed view and on all its nonclustered and XML indexes. 不支援空間索引。Spatial indexes are not supported.
  • 從 SQL Server 2016 開始,保存計算資料行、 UDT 資料行和篩選的索引上額外的檢查不會執行預設以避免昂貴的運算式評估。Starting with SQL Server 2016, additional checks on persisted computed columns, UDT columns, and filtered indexes will not run by default to avoid the expensive expression evaluations. 這項變更可大幅減少 CHECKDB 期間,針對包含這些物件的資料庫。This change greatly reduces the duration of CHECKDB against databases containing these objects. 不過,這些物件的實體一致性檢查一律會完成。However, the physical consistency checks of these objects is always completed. 指定 EXTENDED_LOGICAL_CHECKS 選項時,才將運算式評估執行除了已經存在的邏輯檢查 (索引檢視表、 XML 索引和空間索引) EXTENDED_LOGICAL_CHECKS 選項的一部分。Only when EXTENDED_LOGICAL_CHECKS option is specified will the expression evaluations be performed in addition to already present logical checks (indexed view, XML indexes, and spatial indexes) as part of the EXTENDED_LOGICAL_CHECKS option.

若要了解資料庫的相容性層級To learn the compatibility level of a database

內部資料庫快照集Internal Database Snapshot

DBCC CHECKDB 使用內部資料庫快照集來維護執行這些檢查時所需的交易一致性。DBCC CHECKDB uses an internal database snapshot for the transactional consistency needed to perform these checks. 這可以防止在執行這些命令時,發生封鎖和並行問題。This prevents blocking and concurrency problems when these commands are executed. 如需詳細資訊,請參閱檢視資料庫快照集 ( 的疏鬆檔案大小TRANSACT-SQL )和 DBCC 內部資料庫快照集使用方式 > 一節中的DBCC (TRANSACT-SQL ).For more information, see View the Size of the Sparse File of a Database Snapshot (Transact-SQL) and the DBCC Internal Database Snapshot Usage section in DBCC (Transact-SQL). 如果無法建立快照集,或指定了 TABLOCK,則 DBCC CHECKDB 會獲取鎖定來取得必要的一致性。If a snapshot cannot be created, or TABLOCK is specified, DBCC CHECKDB acquires locks to obtain the required consistency. 在這個情況下,則需要獨佔資料庫鎖定,才能執行配置檢查,而且需要共用資料表鎖定,才能執行資料表檢查。In this case, an exclusive database lock is required to perform the allocation checks, and shared table locks are required to perform the table checks. 如果無法建立內部資料庫快照集,針對主機執行時,DBCC CHECKDB 會失敗。DBCC CHECKDB fails when run against master if an internal database snapshot cannot be created. 針對 tempdb 執行 DBCC CHECKDB 不會執行任何配置或目錄檢查,而且必須取得共用的資料表鎖定來執行資料表檢查。Running DBCC CHECKDB against tempdb does not perform any allocation or catalog checks and must acquire shared table locks to perform table checks. 這是因為基於效能的考量,tempdb 並無法使用資料庫快照集。This is because, for performance reasons, database snapshots are not available on tempdb. 這表示無法取得必要的交易一致性。This means that the required transactional consistency cannot be obtained. 在 Microsoft SQL Server 2012 或更早版本的 SQL Server,您可能會遇到錯誤訊息時執行 DBCC CHECKDB 命令都有其檔案位於 ReFS 格式化的磁碟區上的資料庫。In Microsoft SQL Server 2012 or an earlier version of SQL Server, you may encounter error messages when you run the DBCC CHECKDB command for a database that has its files located on an ReFS-formatted volume. 如需詳細資訊,請參閱知識庫文章 2974455: DBCC CHECKDB 時的 SQL Server 資料庫位於 ReFS 磁碟區上的行為。For more information, see Knowledge Base article 2974455: DBCC CHECKDB behavior when the SQL Server database is located on an ReFS volume.

檢查及修復 FILESTREAM 資料Checking and Repairing FILESTREAM Data

當啟用 FILESTREAM 的資料庫和資料表時,可以選擇性地儲存varbinary (max)二進位大型物件 (Blob) 檔案系統中的。When FILESTREAM is enabled for a database and table, you can optionally store varbinary(max) binary large objects (BLOBs) in the file system. 當您針對將 BLOB 儲存於檔案系統中的資料庫使用 DBCC CHECKDB 時,DBCC 會檢查檔案系統與資料庫之間的連結層級一致性。When using DBCC CHECKDB on a database that stores BLOBs in the file system, DBCC checks link-level consistency between the file system and database. 例如,如果資料表包含varbinary (max)資料行使用 FILESTREAM 屬性,DBCC CHECKDB 會檢查有無檔案系統目錄和檔案和資料表資料列、 資料行,以及資料行之間的一對一對應值。For example, if a table contains a varbinary(max) column that uses the FILESTREAM attribute, DBCC CHECKDB will check that there is a one-to-one mapping between file system directories and files and table rows, columns, and column values. 如果您指定 REPAIR_ALLOW_DATA_LOSS 選項,則 DBCC CHECKDB 可以修復損毀。DBCC CHECKDB can repair corruption if you specify the REPAIR_ALLOW_DATA_LOSS option. 為了修復 FILESTREAM 損毀,DBCC 將刪除遺失檔案系統資料的任何資料表資料列。To repair FILESTREAM corruption, DBCC will delete any table rows that are missing file system data.

最佳作法Best Practices

我們建議您在實際執行系統上,使用 PHYSICAL_ONLY 選項做為常用的選項。We recommend that you use the PHYSICAL_ONLY option for frequent use on production systems. 使用 PHYSICAL_ONLY 可以大幅縮減在大型資料庫上執行 DBCC CHECKDB 所需的時間。Using PHYSICAL_ONLY can greatly shorten run-time for DBCC CHECKDB on large databases. 我們也建議您不搭配使用任何選項,定期執行 DBCC CHECKDB。We also recommend that you periodically run DBCC CHECKDB with no options. 執行這些作業的頻率是依個別公司及其實際執行環境而定。How frequently you should perform these runs depends on individual businesses and their production environments.

平行檢查物件Checking Objects in Parallel

依預設,DBCC CHECKDB 會執行物件的平行檢查。By default, DBCC CHECKDB performs parallel checking of objects. 查詢處理器會自動判斷平行處理原則的程度。The degree of parallelism is automatically determined by the query processor. 最大平行處理原則程度的設定方式與平行查詢相同。The maximum degree of parallelism is configured just like parallel queries. 若要限制 DBCC 檢查可用的處理器數目上限,請使用sp_configureTo restrict the maximum number of processors available for DBCC checking, use sp_configure. 如需詳細資訊,請參閱 設定 max degree of parallelism 伺服器組態選項For more information, see Configure the max degree of parallelism Server Configuration Option. 您可以利用追蹤旗標 2528 來停用平行檢查。Parallel checking can be disabled by using trace flag 2528. 如需詳細資訊,請參閱追蹤旗標 (Transact-SQL)For more information, see Trace Flags (Transact-SQL).

注意

並非所有 SQL ServerSQL Server版本都提供此功能。This feature is not available in every edition of SQL ServerSQL Server. 如需詳細資訊,請參閱 < 平行一致性檢查的 RDBMS 管理能力 > 一節中支援的 SQL Server 2016 的版本功能For more information, see parallel consistency check in the RDBMS Manageability section of Features Supported by the Editions of SQL Server 2016.

了解 DBCC 錯誤訊息Understanding DBCC Error Messages

DBCC CHECKDB 命令執行完成之後, SQL ServerSQL Server 錯誤記錄檔中會寫入一則訊息。After the DBCC CHECKDB command finishes, a message is written to the SQL ServerSQL Server error log. 如果 DBCC 命令執行成功,該訊息將指出命令已順利完成,並顯示命令執行的時間量。If the DBCC command successfully executes, the message indicates success and the amount of time that the command ran. 如果 DBCC 命令由於發生錯誤而在完成檢查之前停止執行,則訊息會指出命令已經結束,並顯示狀態值以及命令執行的時間量。If the DBCC command stops before completing the check because of an error, the message indicates that the command was terminated, a state value, and the amount of time the command ran. 下表列出並描述可以包含在訊息中的狀態值。The following table lists and describes the state values that can be included in the message.

StateState DescriptionDescription
00 已引發錯誤號碼 8930。Error number 8930 was raised. 這表示中繼資料中的損毀導致 DBCC 命令結束。This indicates a corruption in metadata that terminated the DBCC command.
11 已引發錯誤號碼 8967。Error number 8967 was raised. 發生內部 DBCC 錯誤。There was an internal DBCC error.
22 修復緊急模式資料庫期間發生失敗。A failure occurred during emergency mode database repair.
33 這表示中繼資料中的損毀導致 DBCC 命令結束。This indicates a corruption in metadata that terminated the DBCC command.
44 偵測到判斷提示或存取違規。An assert or access violation was detected.
55 發生使 DBCC 命令終止的未知錯誤。An unknown error occurred that terminated the DBCC command.

錯誤報告Error Reporting

傾印檔案 (SQLDUMPnnnn.txt) 中建立 SQL ServerSQL Server每當 DBCC CHECKDB 偵測到損毀錯誤時的記錄檔目錄。A dump file (SQLDUMPnnnn.txt) is created in the SQL ServerSQL Server LOG directory whenever DBCC CHECKDB detects a corruption error. SQL ServerSQL Server 的執行個體已啟用「功能使用方式」資料收集及「錯誤報告」功能時,這個檔案會自動轉送到 MicrosoftMicrosoftWhen the Feature Usage data collection and Error Reporting features are enabled for the instance of SQL ServerSQL Server, the file is automatically forwarded to MicrosoftMicrosoft. 收集的資料是用來提升 SQL ServerSQL Server 的功能。The collected data is used to improve SQL ServerSQL Server functionality. 傾印檔案包含 DBCC CHECKDB 命令的結果以及其他診斷輸出。The dump file contains the results of the DBCC CHECKDB command and additional diagnostic output. 存取限於 SQL ServerSQL Server服務帳戶和系統管理員角色的成員。Access is limited to the SQL ServerSQL Server service account and members of the sysadmin role. 根據預設,系統管理員角色包含 Windows BUILTIN\Administrators 群組和本機系統管理員群組的所有成員。By default, the sysadmin role contains all members of the Windows BUILTIN\Administrators group and the local administrator's group. 如果資料收集程序失敗,DBCC 命令不會失敗。The DBCC command does not fail if the data collection process fails.

解決錯誤Resolving Errors

如果 DBCC CHECKDB 報告任何錯誤,建議您從資料庫備份還原資料庫,而不要設定下列 REPAIR 選項之一來執行 REPAIR。If any errors are reported by DBCC CHECKDB, we recommend restoring the database from the database backup instead of running REPAIR with one of the REPAIR options. 如果沒有任何備份,執行修復可以更正所報告的錯誤。If no backup exists, running repair corrects the errors reported. 要用的 REPAIR 選項指定在報告的錯誤清單尾端。The repair option to use is specified at the end of the list of reported errors. 不過,利用 REPAIR_ALLOW_DATA_LOSS 選項來更正錯誤,可能需要刪除某些頁面,因而也需要刪除某些資料。However, correcting the errors by using the REPAIR_ALLOW_DATA_LOSS option might require deleting some pages, and therefore some data. 在某些情況下,可能會將對資料行的資料類型無效或超出範圍的值輸入資料庫中。Under some circumstances, values might be entered into the database that are not valid or out-of-range based on the data type of the column. DBCC CHECKDB 可以偵側到對所有資料行資料類型無效的資料行值。DBCC CHECKDB can detect column values that are not valid for all column data types. 因此,配合 DATA_PURITY 選項對從舊版 SQL ServerSQL Server 升級的資料庫執行 DBCC CHECKDB,可以發現預先存在的資料行值錯誤。Therefore, running DBCC CHECKDB with the DATA_PURITY option on databases that have been upgraded from earlier versions of SQL ServerSQL Server might reveal preexisting column-value errors. 因為 SQL ServerSQL Server 無法自動修復這些錯誤,所以資料行值必須手動更新。Because SQL ServerSQL Server cannot automatically repair these errors, the column value must be manually updated. 如果 CHECKDB 偵測到這類錯誤,CHECKDB 會傳回警告、錯誤碼 2570,以及識別受影響之資料列和手動更正錯誤的資訊。If CHECKDB detects such an error, CHECKDB returns a warning, the error number 2570, and information to identify the affected row and manually correct the error. 修復動作可在某項使用者交易之下執行,讓使用者可以回復所做的變更。The repair can be performed under a user transaction to let the user roll back the changes that were made. 如果回復修復,資料庫仍會包含錯誤,且必須從備份中還原。If repairs are rolled back, the database will still contain errors and must be restored from a backup. 修復動作完成之後,請備份資料庫。After repairs are completed, back up the database.

以資料庫緊急模式解決錯誤Resolving Errors in Database Emergency Mode

當資料庫已設定為緊急模式使用ALTER DATABASE陳述式中,DBCC CHECKDB 可以執行一些特殊的修復資料庫上如果已指定 REPAIR_ALLOW_DATA_LOSS 選項。When a database has been set to emergency mode by using the ALTER DATABASE statement, DBCC CHECKDB can perform some special repairs on the database if the REPAIR_ALLOW_DATA_LOSS option is specified. 這些修復可讓一般無法修復的資料庫以實體一致的狀態重新上線。These repairs may allow for ordinarily unrecoverable databases to be brought back online in a physically consistent state. 只有在資料庫無法從備份還原時,才應該使用上述修復來當做最後手段。These repairs should be used as a last resort and only when you cannot restore the database from a backup. 當資料庫設定為緊急模式時,將資料庫標示為 READ_ONLY、 記錄已停用,而且存取限於 sysadmin 固定的伺服器角色的成員。When the database is set to emergency mode, the database is marked READ_ONLY, logging is disabled, and access is limited to members of the sysadmin fixed server role.

注意

使用緊急模式時,無法在使用者交易內執行 DBCC CHECKDB 命令並在執行後回復交易。You cannot run the DBCC CHECKDB command in emergency mode inside a user transaction and roll back the transaction after execution.

當資料庫處於緊急模式且執行了 DBCC CHECKDB (具有 REPAIR_ALLOW_DATA_LOSS 子句) 時,將會採取下列動作:When the database is in emergency mode and DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS clause is run, the following actions are taken:

  • DBCC CHECKDB 會使用因 I/O 或總和檢查碼錯誤而標示為無法存取的頁面,如同未發生錯誤一樣。DBCC CHECKDB uses pages that have been marked inaccessible because of I/O or checksum errors, as if the errors have not occurred. 執行這個動作,可增加從資料庫復原資料的機會。Doing this increases the chances for data recovery from the database.
  • DBCC CHECKDB 會試圖利用正規記錄式復原技術來復原資料庫。DBCC CHECKDB attempts to recover the database using regular log-based recovery techniques.
  • 如果資料庫復原因交易記錄損毀而無法成功,就會重建交易記錄。If, because of transaction log corruption, database recovery is unsuccessful, the transaction log is rebuilt. 重建交易記錄可能會導致無法維持交易一致性。Rebuilding the transaction log may result in the loss of transactional consistency.

警告

REPAIR_ALLOW_DATA_LOSS 選項是 SQL ServerSQL Server 支援的功能。The REPAIR_ALLOW_DATA_LOSS option is a supported feature of SQL ServerSQL Server. 不過,這個選項不一定是讓資料庫處於實體一致狀態的最佳選項。However, it may not always be the best option for bringing a database to a physically consistent state. 如果成功的話,REPAIR_ALLOW_DATA_LOSS 選項可能會導致部分資料遺失。If successful, the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. 事實上,這個選項遺失的資料,可能會比使用者從上次已知良好備份還原資料庫所遺失的資料多。In fact, it may result in more data lost than if a user were to restore the database from the last known good backup. MicrosoftMicrosoft 一律建議使用者從上次已知良好的備份還原,做為修復 DBCC CHECKDB 所報告之錯誤的主要方法。 always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. REPAIR_ALLOW_DATA_LOSS 選項無法取代從已知良好的備份還原方法。The REPAIR_ALLOW_DATA_LOSS option is not an alternative for restoring from a known good backup. 只有在不可能從備份還原時,才建議使用這個「上次還原」緊急選項。It is an emergency “last resort” option recommended for use only if restoring from a backup is not possible.

重建記錄檔之後,不保證會有完整的 ACID。After rebuilding the log, there is no full ACID guarantee.

重建記錄檔之後,系統會自動執行 DBCC CHECKDB,並會同時回報及更正實體一致性問題。After rebuilding the log, DBCC CHECKDB will be automatically performed and will both report and correct physical consistency issues.

您必須手動驗證邏輯資料一致性和商務邏輯這兩個條件約束。Logical data consistency and business logic enforced constraints must be validated manually.

交易記錄檔大小會保持為其預設大小,因此必須手動調整回最新的大小。The transaction log size will be left to its default size and must be manually adjusted back to its recent size.

如果 DBCC CHECKDB 命令成功完成,則資料庫會處於實體一致的狀態,且資料庫狀態會設為 ONLINE。If the DBCC CHECKDB command succeeds, the database is in a physically consistent state and the database status is set to ONLINE. 不過,資料庫可能會包含一個或多個交易不一致的狀況。However, the database may contain one or more transactional inconsistencies. 我們建議您執行DBCC CHECKCONSTRAINTS找出任何商務邏輯的缺陷,並立即備份資料庫。We recommend that you run DBCC CHECKCONSTRAINTS to identify any business logic flaws and immediately back up the database. 如果 DBCC CHECKDB 命令失敗,資料庫就無法修復。If the DBCC CHECKDB command fails, the database cannot be repaired.

在複寫的資料庫中搭配執行 DBCC CHECKDB 與 REPAIR_ALLOW_DATA_LOSSRunning DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS in Replicated Databases

搭配執行 DBCC CHECKDB 命令與 REPAIR_ALLOW_DATA_LOSS 選項時,可能會影響使用者資料庫 (發行集和訂閱資料庫) 以及複寫所使用的散發資料庫。Running the DBCC CHECKDB command with the REPAIR_ALLOW_DATA_LOSS option can affect user databases (publication and subscription databases) and the distribution database used by replication. 發行集和訂閱資料庫包含已發行資料表和複寫中繼資料表。Publication and subscription databases include published tables and replication metadata tables. 請注意這些資料庫中的下列潛在問題:Be aware of the following potential issues in these databases:

  • 已發行資料表。Published tables. 由 CHECKDB 處理序執行以修復損毀使用者資料的動作可能並未複寫:Actions performed by the CHECKDB process to repair corrupt user data might not be replicated:
  • 合併式複寫使用觸發程序來追蹤已發行之資料表的變更。Merge replication uses triggers to track changes to published tables. 如果資料列是由 CHECKDB 處理序插入、更新或刪除,將不會引發觸發程序;因此,也不會複寫變更。If rows are inserted, updated, or deleted by the CHECKDB process, triggers do not fire; therefore, the change is not replicated.
  • 異動複寫使用交易記錄來追蹤已發行之資料表的變更。Transactional replication uses the transaction log to track changes to published tables. 記錄讀取器代理程式接著會將這些變更移到散發資料庫。The Log Reader Agent then moves these changes to the distribution database. 某些 DBCC 修復雖然已經記錄,但卻不能由記錄讀取器代理程式加以複寫。Some DBCC repairs, although logged, cannot be replicated by the Log Reader Agent. 例如,如果資料頁已由 CHECKDB 處理序取消配置,記錄讀取器代理程式就不會將它轉譯成 DELETE 陳述式;因此,也不會複寫變更。For example, if a data page is deallocated by the CHECKDB process, the Log Reader Agent does not translate this to a DELETE statement; therefore, the change is not replicated.
  • 複寫中繼資料表。Replication metadata tables. 由 CHECKDB 處理序執行以修復損毀複寫中繼資料表的動作需要移除及重新設定複寫。Actions performed by the CHECKDB process to repair corrupt replication metadata tables require removing and reconfiguring replication.

如果您必須在使用者資料庫或散發資料庫上搭配執行 DBCC CHECKDB 命令與 REPAIR_ALLOW_DATA_LOSS 選項:If you have to run the DBCC CHECKDB command with the REPAIR_ALLOW_DATA_LOSS option on a user database or distribution database:

  1. 停止系統:停止該資料庫以及複寫拓撲中其他所有資料庫的活動,然後嘗試同步處理所有節點。Quiesce the system: Stop activity on the database and at all other databases in the replication topology, and then try to synchronize all nodes. 如需詳細資訊,請參閱停止複寫拓撲 (複寫 Transact-SQL 程式設計)For more information, see Quiesce a Replication Topology (Replication Transact-SQL Programming).
  2. 執行 DBCC CHECKDB。Execute DBCC CHECKDB.
  3. 如果 DBCC CHECKDB 報表包含散發資料庫中任何資料表的修復,或包含使用者資料庫中任何複寫中繼資料表的修復,請移除並重新設定複寫。If the DBCC CHECKDB report includes repairs for any tables in the distribution database or any replication metadata tables in a user database, remove and reconfigure replication. 如需詳細資訊,請參閱停用發行和散發For more information, see Disable Publishing and Distribution.
  4. 如果 DBCC CHECKDB 報表包含任何已複寫資料表的修復,請執行資料驗證以判斷發行集與訂閱資料庫之間的資料是否有差異。If the DBCC CHECKDB report includes repairs for any replicated tables, perform data validation to determine whether there are differences between the data in the publication and subscription databases.

結果集Result Sets

DBCC CHECKDB 會傳回下列結果集。DBCC CHECKDB returns the following result set. 這些值可能會不同,除非指定了 ESTIMATEONLY、PHYSICAL_ONLY 或 NO_INFOMSGS 選項:The values might vary except when the ESTIMATEONLY, PHYSICAL_ONLY, or NO_INFOMSGS options are specified:

 DBCC results for 'model'.    

 Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.    

 Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.    

 Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.    

 Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.    

 Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.    

 Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.    

 Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.    

 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 0 rows in 0 pages for object "sys.sysasymkeys".    

 DBCC results for 'sys.syssqlguides'.    

 There are 0 rows in 0 pages for object "sys.syssqlguides".    

 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".    

 CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.    

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

指定 NO_INFOMSGS 時,DBCC CHECKDB 會傳回下列結果集 (訊息):DBCC CHECKDB returns the following result set (message) when NO_INFOMSGS is specified:

 The command(s) completed successfully.

指定 PHYSICAL_ONLY 時,DBCC CHECKDB 會傳回下列結果集:DBCC CHECKDB returns the following result set when PHYSICAL_ONLY is specified:

 DBCC results for 'model'.    

 CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.  

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

指定 ESTIMATEONLY 時,DBCC CHECKDB 會傳回下列結果集。DBCC CHECKDB returns the following result set when ESTIMATEONLY is specified.

 Estimated TEMPDB space needed for CHECKALLOC (KB)    

 -------------------------------------------------  

 13   

 (1 row(s) affected)   

 Estimated TEMPDB space needed for CHECKTABLES (KB)    

 --------------------------------------------------    

 57 

 (1 row(s) affected)  

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

PermissionsPermissions

需要 sysadmin 固定伺服器角色或 db_owner 固定資料庫角色的成員資格。Requires membership in the sysadmin fixed server role or the db_owner fixed database role.

範例Examples

A.A. 同時檢查目前的資料庫與另一個資料庫Checking both the current and another database

下列範例會針對目前資料庫和 DBCC CHECKDB 資料庫執行 AdventureWorks2012AdventureWorks2012The following example executes DBCC CHECKDB for the current database and for the AdventureWorks2012AdventureWorks2012 database.

-- Check the current database.    
DBCC CHECKDB;    
GO    
-- Check the AdventureWorks2012 database without nonclustered indexes.    
DBCC CHECKDB (AdventureWorks2012, NOINDEX);    
GO    

B.B. 檢查目前的資料庫,隱藏參考訊息Checking the current database, suppressing informational messages

下列範例會檢查目前資料庫,且隱藏所有參考訊息。The following example checks the current database and suppresses all informational messages.

DBCC CHECKDB WITH NO_INFOMSGS;    
GO    

另請參閱See Also

DBCC (Transact-SQL)DBCC (Transact-SQL)
檢視資料庫快照集的疏鬆檔案大小 (Transact-SQL)View the Size of the Sparse File of a Database Snapshot (Transact-SQL)
sp_helpdb (TRANSACT-SQL )sp_helpdb (Transact-SQL)
系統資料表 (TRANSACT-SQL )System Tables (Transact-SQL)