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

적용 대상:Applies to: 예SQL ServerSQL Server(지원되는 모든 버전)yesSQL ServerSQL Server (all supported versions) 예Azure SQL DatabaseAzure SQL DatabaseYesAzure SQL DatabaseAzure SQL Database적용 대상:Applies to: 예SQL ServerSQL Server(지원되는 모든 버전)yesSQL ServerSQL Server (all supported versions) 예Azure SQL DatabaseAzure SQL DatabaseYesAzure SQL DatabaseAzure SQL Database

지정한 데이터베이스에서 다음 작업을 수행하여 모든 개체의 논리적 무결성 및 물리적 무결성을 검사합니다.Checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

  • 데이터베이스에 대해 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.
  • FILESTREAM을 사용하여 파일 시스템에 varbinary(max) 데이터를 저장할 때 테이블 메타데이터와 파일 시스템 디렉터리 및 파일 간의 연결 수준 일관성에 대한 유효성을 검사합니다.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.

참고

DBCC CHECKDB는 메모리 최적화 테이블을 포함하는 데이터베이스에서 지원되지만 유효성 검사는 디스크 기반 테이블에서만 수행됩니다.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.

항목 링크 아이콘 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 ]    
        }    
    ]    
]    

참고

SQL Server 2014 이전 버전의 Transact-SQL 구문을 보려면 이전 버전 설명서를 참조하세요.To view Transact-SQL syntax for SQL Server 2014 and earlier, see Previous versions documentation.

인수Arguments

database_name | database_id | 0database_name | database_id | 0
무결성 검사를 실행할 데이터베이스의 이름 또는 ID입니다.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.

복구를 수행하기 전에 데이터베이스 상태를 EMERGENCY 모드로 변경하고 중요 테이블에서 가능한 한 많은 정보를 추출하고 해당 데이터를 저장하는 것이 좋습니다.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 nonclustered 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에서는 항상 사용자가 작업 결과를 허용할지 확인할 수 있도록 트랜잭션 내에서 CHECKDB를 REPAIR 옵션과 함께 사용(명령을 실행하기 전에 BEGIN TRANSACTION 실행)하도록 권장합니다.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 데이터베이스에서 생성된 메시지를 제외한 모든 오류 메시지는 개체 ID를 기준으로 정렬됩니다.Error messages are sorted by object ID, except for those messages generated from tempdb database.    

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.
자세한 내용은 이 항목의 뒤 부분에 나오는 Remarks 섹션에서 인덱스에 대한 논리적 일관성 검사 수행을 참조하세요.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.
    이 인수는 항상 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 ServerSQL Server(SQL Server 2014(12.x)SQL Server 2014 (12.x) SP2 이상).Applies to: SQL ServerSQL Server ( SQL Server 2014(12.x)SQL Server 2014 (12.x) SP2 and later).

명령문에 대한 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가 Resource Governor로 구성한 값을 초과하면 SQL Server 데이터베이스 엔진SQL Server Database EngineALTER WORKLOAD GROUP에서 설명한 Resource Governor MAXDOP 값을 사용합니다.If MAXDOP exceeds the value configured with Resource Governor, the SQL Server 데이터베이스 엔진SQL Server Database Engine uses the Resource Governor MAXDOP value, described in ALTER WORKLOAD GROUP. max degree of parallelism 구성 옵션에 사용된 모든 의미 체계 규칙을 MAXDOP 쿼리 힌트 사용 시 적용할 수 있습니다.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가 0으로 설정되면 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.

리소스 데이터베이스는 단일 사용자 모드에서만 수정할 수 있으므로 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를 실행할 때 또 다른 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.

SQL Server 2005(9.x)SQL Server 2005 (9.x) SP2부터 DBCC CHECKDB를 실행하면 SQL ServerSQL Server 인스턴스에 대한 계획 캐시가 삭제되지 않습니다.Starting with SQL Server 2005(9.x)SQL Server 2005 (9.x) SP2, executing DBCC CHECKDB no longer clears the plan cache for the instance of SQL ServerSQL Server. SQL Server 2005(9.x)SQL Server 2005 (9.x) SP2 이전에서는 DBCC CHECKDB를 실행하면 계획 캐시가 삭제됩니다.Before SQL Server 2005(9.x)SQL Server 2005 (9.x) SP2, executing DBCC CHECKDB clears the plan cache. 계획 캐시를 삭제하면 모든 후속 실행 계획이 다시 컴파일되며 일시적으로 갑자기 쿼리 성능이 저하될 수 있습니다.Clearing the plan cache causes recompilation of all later execution plans and may cause a sudden, temporary decrease in query performance.

인덱스에 대한 논리적 일관성 검사 수행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:
  • DBCC CHECKDB는 NOINDEX가 지정되지 않으면 단일 테이블 및 해당하는 모든 비클러스터형 인덱스에 대해 물리적 및 논리적 일관성 검사를 모두 수행합니다.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 이하인 경우 DBCC CHECKDB는 NOINDEX가 지정되지 않으면 단일 테이블 또는 인덱싱된 뷰와 해당하는 모든 비클러스터형 인덱스 및 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 옵션을 지정하는 경우에만 EXTENDED_LOGICAL_CHECKS 옵션의 일부로 기존의 논리적 검사(인덱싱된 뷰, XML 인덱스, 공간 인덱스)와 함께 식 평가가 수행됩니다.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 (Transact-SQL)의 "DBCC 내부 데이터베이스 스냅샷 사용법" 섹션을 참조하세요.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 버전에서는 ReFS로 포맷된 볼륨에 파일이 있는 데이터베이스에 대해 DBCC CHECKDB 명령을 실행하면 오류 메시지가 발생할 수 있습니다.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: SQL Server 데이터베이스가 ReFS 볼륨에 있는 경우 DBCC CHECKDB 동작을 참조하세요.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(Binary Large Object)를 저장할 수 있습니다.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. 예를 들어 테이블에 FILESTREAM 특성을 사용하는 varbinary(max) 열이 있는 경우 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_configure를 사용합니다.To 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. 자세한 내용은 SQL Server 2016 버전에서 지원하는 기능의 RDBMS 관리 효율성 섹션에 있는 병렬 일관성 검사를 참조하세요.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.

시스템 상태State 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.

참고

SQL ServerSQL Server는 오류 없이 데이터베이스 일관성 확인(또는 "깨끗한" 일관성 확인)이 실행된 날짜와 시간을 기록합니다.records the date and time when a consistency check was run for a database with no errors (or "clean" consistency check). 이것을 last known clean check라고 합니다.This is known as the last known clean check. 데이터베이스가 처음 시작될 때 이 날짜는 EventLog(EventID-17573) 및 ERRORLOG에 다음과 같은 형식으로 기록됩니다.When a database is first started, this date is written to the EventLog (EventID-17573) and ERRORLOG in the following format:

CHECKDB for database '<database>' finished without errors on 2019-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

오류 보고Error Reporting

DBCC CHECKDB가 손상 오류를 감지할 때마다 SQL ServerSQL Server LOG 디렉터리에 덤프 파일(SQLDUMP*nnnn*.txt)이 생성됩니다.A dump file (SQLDUMP*nnnn*.txt) is created in the SQL ServerSQL Server LOG directory whenever DBCC CHECKDB detects a corruption error. SQL ServerSQL Server 인스턴스에 대해 기능 사용 데이터 수집 및 오류 보고 기능을 설정하면 이 파일이 MicrosoftMicrosoft에 자동으로 전달됩니다.When 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 서비스 계정 및 sysadmin 역할의 멤버로 제한됩니다.Access is limited to the SQL ServerSQL Server service account and members of the sysadmin role. 기본적으로 sysadmin 역할에는 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. 백업이 없을 경우 REPAIR를 실행하면 보고된 오류를 수정할 수 있습니다.If no backup exists, running repair corrects the errors reported. 사용할 복구 옵션은 보고된 오류 목록 끝에 지정됩니다.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. 따라서 이전 버전의 SQL ServerSQL Server에서 업그레이드된 데이터베이스에서 DATA_PURITY 옵션을 사용해 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는 이러한 오류를 검색하면 경고 및 오류 번호 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 문을 사용하여 데이터베이스가 응급 모드로 설정된 경우 REPAIR_ALLOW_DATA_LOSS 옵션을 지정하면 DBCC CHECKDB는 데이터베이스에 대해 특별한 복구 작업을 수행할 수 있습니다.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.

데이터베이스가 응급 모드에 있고 REPAIR_ALLOW_DATA_LOSS 절이 있는 DBCC CHECKDB를 실행하면 다음 동작이 수행됩니다.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.

복제된 데이터베이스에서 REPAIR_ALLOW_DATA_LOSS 옵션으로 DBCC CHECKDB 실행Running DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS in Replicated Databases

REPAIR_ALLOW_DATA_LOSS 옵션으로 DBCC CHECKDB 명령을 실행하면 사용자 데이터베이스(게시 및 구독 데이터베이스)와 복제에 사용되는 배포 데이터베이스에 영향을 줄 수 있습니다.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.

사용자 데이터베이스 또는 배포 데이터베이스에 대해 REPAIR_ALLOW_DATA_LOSS 옵션으로 DBCC CHECKDB 명령을 실행해야 하는 경우 다음 작업을 수행합니다.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.    

DBCC CHECKDB는 NO_INFOMSGS가 지정되었을 때 다음과 같은 결과 집합(메시지)을 반환합니다.DBCC CHECKDB returns the following result set (message) when NO_INFOMSGS is specified:

 The command(s) completed successfully.

DBCC CHECKDB는 PHYSICAL_ONLY가 지정되었을 때 다음 결과 집합을 반환합니다.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.

DBCC CHECKDB는 ESTIMATEONLY가 지정되었을 때 다음 결과 집합을 반환합니다.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.

사용 권한Permissions

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 데이터베이스에 대해 AdventureWorks2012AdventureWorks2012를 실행합니다.The 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)