DBCC CHECKDB(Transact-SQL)

업데이트: 2008년 11월 17일

지정한 데이터베이스에서 다음 작업을 수행하여 모든 개체의 논리적 무결성 및 물리적 무결성을 검사합니다.

• 데이터베이스에 대해 DBCC CHECKALLOC를 실행합니다.
• 데이터베이스의 모든 테이블 및 뷰에 대해 DBCC CHECKTABLE을 실행합니다.
• 데이터베이스에 대해 DBCC CHECKCATALOG를 실행합니다.
• 데이터베이스에 있는 모든 인덱싱된 뷰의 내용에 대한 유효성을 검사합니다.
• 데이터베이스에 있는 Service Broker 데이터의 유효성을 검사합니다.

이는 DBCC CHECKALLOC, DBCC CHECKTABLE 또는 DBCC CHECKCATALOG 명령을 DBCC CHECKDB와 별도로 실행할 필요가 없음을 의미합니다. 이러한 명령이 수행하는 검사에 대한 자세한 내용은 해당 명령의 설명을 참조하십시오.

Transact-SQL 구문 표기 규칙

구문

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

인수

• database_name | database_id | 0
  무결성 검사를 실행할 데이터베이스의 이름 또는 ID입니다. 아무 값도 지정하지 않거나 0을 지정하면 현재 데이터베이스가 사용됩니다. 데이터베이스 이름은 식별자에 대한 규칙을 따라야 합니다.

• NOINDEX
  사용자 테이블의 비클러스터형 인덱스에 대해 집중적인 검사가 수행되지 않도록 지정합니다. 이렇게 하면 전반적인 실행 시간이 줄어듭니다. 시스템 테이블 인덱스에서는 무결성 검사가 항상 수행되므로 NOINDEX는 시스템 테이블에 영향을 주지 않습니다.

• REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
  DBCC CHECKDB 실행 시 검색된 오류를 복구하도록 지정합니다. 다음 복구 옵션 중 하나를 사용하려면 지정된 데이터베이스가**단일 사용자 모드여야 합니다.

  • REPAIR_ALLOW_DATA_LOSS
    보고된 모든 오류를 복구합니다. 이러한 복구를 수행하면 일부 데이터가 손실될 수 있습니다.
  • REPAIR_FAST
    이전 버전과의 호환성을 위해서만 구문을 유지 관리합니다. 복구 작업은 수행되지 않습니다.
  • REPAIR_REBUILD
    비클러스터형 인덱스의 추가 키 복구와 같은 사소하고 빠른 복구 작업과 인덱스 다시 작성과 같이 시간이 오래 걸리는 복구를 모두 수행합니다. 이러한 복구는 데이터 손실의 위험 없이 수행할 수 있습니다.

  중요:
  REPAIR 옵션을 최후의 수단으로만 사용합니다. 오류를 복구하려면 백업에서 복원하는 것이 좋습니다. 복구 작업이 수행될 경우 테이블 자체나 테이블 간에 존재할 수 있는 제약 조건이 고려되지 않습니다. 지정된 테이블이 하나 이상의 제약 조건에 관련되면 복구 작업 후에 DBCC CHECKCONSTRAINTS를 실행하는 것이 좋습니다. REPAIR를 사용해야 하는 경우 복구 옵션 없이 DBCC CHECKDB를 실행하여 사용할 복구 수준을 확인합니다. REPAIR_ALLOW_DATA_LOSS 수준을 사용하는 경우 이 옵션으로 DBCC CHECKDB를 실행하기 전에 데이터베이스를 백업하는 것이 좋습니다.

• ALL_ERRORMSGS
  개체당 지원되는 모든 오류를 표시합니다. SQL Server 2005 서비스 팩 3(SP3)에서는 기본적으로 모든 오류 메시지가 표시됩니다. 이 옵션을 지정하거나 생략하더라도 아무런 영향이 없습니다. 이전 버전의 SQL Server에서는 ALL_ERRORMSGS를 지정하지 않으면 각 개체에 대해 처음 200개의 오류 메시지만 표시됩니다. tempdb 데이터베이스에서 생성된 메시지를 제외한 모든 오류 메시지는 개체 ID를 기준으로 정렬됩니다.

  SQL Server Management Studio의 경우 반환되는 오류 메시지의 최대 개수는 1000개입니다. Management Studio에서는 ALL_ERRORMSGS가 지정된 경우 오류의 전체 목록을 가져오려면 DBCC CHECKDB를 여러 번 실행해야 할 수도 있습니다. 명령을 실행하고 출력을 파일로 보내려면 sqlcmd 유틸리티를 사용하거나 SQL Server 에이전트 작업을 예약하여 DBCC 명령을 실행하는 것이 좋습니다. 이러한 방법을 사용할 경우 명령을 한 번 실행하면 모든 오류 메시지가 보고됩니다.

• NO_INFOMSGS
  모든 정보 메시지를 표시하지 않습니다.

• TABLOCK
  내부 데이터베이스 스냅숏을 사용하는 대신 DBCC CHECKDB가 데이터베이스를 잠그도록 설정합니다. 여기에는 데이터베이스에 대한 단기 배타(X) 잠금이 포함됩니다. TABLOCK을 사용하면 데이터베이스에 로드가 많은 상황에서 DBCC CHECKDB가 더 빠르게 실행됩니다. 그러나 DBCC CHECKDB가 실행되는 동안 데이터베이스의 동시 사용 가능성은 줄어듭니다. 잠금에 대한 자세한 내용은 잠금 모드를 참조하십시오.

  TABLOCK은 수행되는 검사를 제한합니다. 데이터베이스에 대해 DBCC CHECKCATALOG가 실행되지 않으며 Service Broker 데이터의 유효성이 검사되지 않습니다.

• ESTIMATEONLY
  지정된 다른 모든 옵션으로 DBCC CHECKDB를 실행하는 데 필요한 tempdb 공간의 예상 크기를 표시합니다. 실제 데이터베이스 검사는 수행되지 않습니다.

• PHYSICAL_ONLY
  페이지 및 레코드 헤더의 물리적 구조의 무결성, B-트리의 물리적 구조 및 데이터베이스 할당 일관성으로 검사를 제한합니다. 이 검사는 데이터베이스의 물리적 일관성 검사의 오버헤드를 줄이기 위한 목적으로 사용하며 사용자의 데이터를 손상시킬 가능성이 있는 조각난 페이지와 체크섬 오류, 그리고 일반적인 하드웨어 오류도 찾을 수 있습니다. PHYSICAL_ONLY는 항상 NO_INFOMSGS를 의미하며 어떠한 복구 옵션과도 함께 사용할 수 없습니다.

• DATA_PURITY
  DBCC CHECKDB가 데이터베이스에서 올바르지 않거나 범위를 벗어난 열 값을 검사하도록 합니다. 예를 들어 DBCC CHECKDB는 datetime 데이터 형식으로 허용 가능한 범위보다 크거나 작은 날짜 및 시간 값을 가진 열을 검색하거나, 올바르지 않은 소수 자릿수 또는 전체 자릿수 값을 가진 decimal 또는 근사치 데이터 형식의 열을 검색할 수 있습니다.

  SQL Server 2005에서 생성된 데이터베이스의 경우 기본적으로 열 값 무결성 검사가 사용되며 DATA_PURITY 옵션은 필요하지 않습니다. 이전 버전의 SQL Server에서 업그레이드한 데이터베이스의 경우에는 DBCC CHECKDB WITH DATA_PURITY가 데이터베이스에서 오류 없이 실행되기 전까지는 열 값 검사가 기본적으로 사용되지 않습니다. 이 옵션이 성공적으로 실행되면 DBCC CHECKDB는 기본적으로 열 값 무결성을 검사합니다. 이전 버전의 SQL Server에서 데이터베이스를 업그레이드함에 따라 CHECKDB가 어떤 영향을 받는지에 대한 자세한 내용은 이 항목의 뒷부분에 나오는 주의 섹션을 참조하십시오.

  PHYSICAL_ONLY를 지정하면 열 무결성 검사는 수행되지 않습니다.

  이 옵션에서 보고된 유효성 검사 오류는 DBCC 복구 옵션을 사용하여 수정할 수 없습니다. 이러한 오류를 수동으로 수정하는 방법은 기술 자료 문서 923247: SQL Server 2005에서 DBCC 오류 2570 문제 해결(Troubleshooting DBCC error 2570 in SQL Server 2005)을 참조하십시오.

결과 집합

DBCC CHECKDB는 다음 결과 집합을 반환합니다. ESTIMATEONLY, PHYSICAL_ONLY 또는 NO_INFOMSGS 옵션이 지정된 경우를 제외하고는 값이 다를 수 있습니다.

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가 지정되었을 때 다음과 같은 결과 집합(메시지)을 반환합니다.

The command(s) completed successfully.

DBCC CHECKDB는 PHYSICAL_ONLY가 지정되었을 때 다음 결과 집합을 반환합니다.

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

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.

주의

이전 버전의 SQL Server에서는 테이블 및 인덱스당 행 개수 및 페이지 수가 잘못될 수 있습니다. 심지어는 특정한 환경에서 한 개 이상의 이러한 값이 음수가 되는 경우도 있습니다. SQL Server 2005에서 이러한 값은 항상 올바르게 유지 관리됩니다. 그러므로 SQL Server 2005에서 만든 데이터베이스에는 잘못된 개수가 포함되지 않지만 SQL Server 2005로 업그레이드한 데이터베이스에는 포함될 수 있습니다. 데이터베이스에 저장된 데이터가 손상된 것은 아닙니다. 이 개수 중 하나라도 음수가 되면 이를 감지하도록 DBCC CHECKDB가 개선되었습니다. 음수 개수가 감지되면 DBCC CHECKDB 출력에 경고와 함께 DBCC UPDATEUSAGE를 실행하여 문제를 해결하라는 권장 구성이 포함됩니다. SQL Server 2005로의 데이터베이스 업그레이드가 문제의 원인인 것처럼 보이지만 잘못된 개수는 업그레이드 이전부터 존재했던 것입니다.

DBCC CHECKDB는 비활성화된 인덱스는 검사하지 않습니다. 비활성화된 인덱스에 대한 자세한 내용은 인덱스 비활성화를 참조하십시오.

사용자 정의 유형이 바이트 정렬된 것으로 표시되면 사용자 정의 유형의 직렬화가 하나만 있어야 합니다. 바이트 정렬된 사용자 정의 유형의 일관성 있는 직렬화가 없으면 DBCC CHECKDB를 실행할 때 오류 2537이 발생합니다. 자세한 내용은 User-Defined Type Requirements을 참조하십시오.

리소스 데이터베이스는 단일 사용자 모드에서만 수정할 수 있으므로 DBCC CHECKDB 명령은 이 데이터베이스에 대해 직접 실행할 수 없습니다. 하지만 master 데이터베이스에 대해 DBCC CHECKDB를 실행할 때 또 다른 CHECKDB가 리소스 데이터베이스에 대해 내부적으로 실행되므로 DBCC CHECKDB가 추가적인 결과를 반환할 수 있습니다. 옵션을 설정하지 않거나 PHYSICAL_ONLY 또는 ESTIMATEONLY 옵션 중 하나를 설정하면 추가적인 결과 집합이 반환됩니다.

SQL Server 2005 SP2 이전 버전에서 DBCC CHECKDB를 실행하면 SQL Server의 인스턴스에 대한 계획 캐시가 삭제됩니다. 계획 캐시를 삭제하면 모든 후속 실행 계획이 다시 컴파일되며 일시적으로 갑자기 쿼리 성능이 저하될 수 있습니다. SP2에서 DBCC CHECKDB를 실행하면 계획 캐시가 삭제되지 않습니다.

내부 데이터베이스 스냅숏

DBCC CHECKDB는 이러한 검사를 수행하는 데 필요한 트랜잭션 일관성을 위해 내부 데이터베이스 스냅숏을 사용합니다. 이렇게 하면 이러한 명령이 실행될 때 차단 및 동시성 문제를 방지할 수 있습니다. 자세한 내용은 데이터베이스 스냅숏의 스파스 파일 크기 이해 및 DBCC(Transact-SQL)의 DBCC 내부 데이터베이스 스냅숏 사용법 섹션을 참조하십시오. 스냅숏을 만들 수 없거나 TABLOCK이 지정되면 DBCC CHECKDB는 필요한 일관성을 확보하기 위해 잠금을 설정합니다. 이 경우 할당 확인을 위해서는 배타적 데이터베이스 잠금이 필요하며 테이블 확인을 위해서는 공유 테이블 잠금이 필요합니다.

내부 데이터베이스 스냅숏을 생성할 수 없는 경우 master에 대한 DBCC CHECKDB 실행은 실패합니다.

tempdb에 대해 DBCC CHECKDB를 실행할 경우 할당 또는 카탈로그 검사는 수행되지 않으며 테이블 검사를 수행하려면 공유 테이블 잠금을 설정해야 합니다. 이것은 성능상의 이유로 tempdb에 대해 데이터베이스 스냅숏을 사용할 수 없기 때문입니다. 즉, 필요한 트랜잭션 일관성을 얻을 수 없음을 의미합니다.

최상의 방법

SQL Server 2005에서 옵션을 지정하지 않고 DBCC CHECKDB를 실행하면 이전 버전보다 시간이 오래 걸릴 수 있습니다. 이 동작은 다음과 같은 이유로 발생합니다.

• 수행하는 논리적 검사가 보다 포괄적입니다.
• 검사할 기본 구조 일부가 좀 더 복잡합니다.
• SQL Server 2005의 새로운 기능을 포괄할 수 있도록 여러 가지 검사 작업이 새로 도입되었습니다.

따라서 프로덕션 시스템에서 자주 사용하려면 PHYSICAL_ONLY 옵션을 사용하는 것이 좋습니다. PHYSICAL_ONLY를 사용하면 큰 데이터베이스에 대한 DBCC CHECKDB 실행 시간이 훨씬 단축될 수 있습니다. 또한 옵션을 지정하지 않고 정기적으로 DBCC CHECKDB를 실행하는 것이 좋습니다. 실행 빈도는 개별 비즈니스 및 프로덕션 환경에 따라 달라집니다.

병렬로 개체 검사

기본적으로 DBCC CHECKDB는 개체를 병렬로 검사합니다. 병렬 처리 수준은 쿼리 프로세서에 의해 자동으로 결정됩니다. 최대 병렬 처리 수준은 병렬 쿼리처럼 구성됩니다. DBCC 검사에 사용할 수 있는 최대 프로세서 수를 제한하려면 sp_configure를 사용합니다. 자세한 내용은 max degree of parallelism 옵션을 참조하십시오. 추적 플래그 2528을 사용하면 병렬 검사를 비활성화할 수 있습니다. 자세한 내용은 추적 플래그(Transact-SQL)를 참조하십시오.

DBCC 오류 메시지 이해

DBCC CHECKDB 명령이 완료된 후 SQL Server 오류 로그에 메시지가 기록됩니다. DBCC 명령이 성공적으로 실행되면 메시지에 성공 및 명령이 실행된 소요 시간이 표시됩니다. 오류로 인해 DBCC 명령이 검사를 완료하기 전에 중지되면 메시지에 명령 종료, 상태 값 및 명령이 실행된 소요 시간이 표시됩니다. 다음 표에서는 메시지에 포함될 수 있는 상태 값을 나열하고 설명합니다.

오류 보고

SQL Server 2005 서비스 팩 1에서는 DBCC CHECKDB가 손상 오류를 감지할 때마다 SQL Server LOG 디렉터리에 덤프 파일(SQLDUMPnnnn.txt)이 생성됩니다. SQL Server 인스턴스에 대해 기능 사용 데이터 수집 및 오류 보고 기능을 설정하면 이 파일이 Microsoft에 자동으로 전달됩니다. 수집된 데이터를 사용하여 SQL Server 기능을 향상시킬 수 있습니다. 자세한 내용은 오류 및 사용 보고서 설정을 참조하십시오.

덤프 파일에는 DBCC CHECKDB 명령의 결과 및 추가 진단 출력이 포함됩니다. 액세스는 SQL Server 서비스 계정 및 sysadmin 역할의 멤버로 제한됩니다. 기본적으로 sysadmin 역할에는 Windows BUILTIN\Administrators 그룹 및 로컬 관리자 그룹의 모든 멤버가 포함됩니다. 데이터 수집 프로세스가 실패해도 DBCC 명령은 실패하지 않습니다.

오류 해결

DBCC CHECKDB에 의해 오류가 보고되면 REPAIR 옵션 중 하나를 사용해 REPAIR를 실행하는 대신 데이터베이스 백업으로부터 데이터베이스를 복원하는 것이 좋습니다. 백업이 없을 경우 REPAIR를 실행하면 보고된 오류를 수정할 수 있습니다. 필요한 REPAIR 옵션은 보고된 오류 목록 끝에 지정됩니다. 하지만 REPAIR_ALLOW_DATA_LOSS 옵션을 사용하여 오류를 수정하면 일부 페이지 및 데이터가 삭제될 수 있습니다.

경우에 따라서는 열의 데이터 형식을 기반으로 데이터베이스에 입력된 값이 잘못되었거나 범위를 벗어날 수 있습니다. SQL Server 2000에서 DBCC CHECKDB는 이 열 값에 대해 범위 또는 무결성 검사를 수행하지 않습니다. 하지만 SQL Server 2005에서는 DBCC CHECKDB가 모든 열 데이터 형식에 대해 올바르지 않은 열 값을 검색할 수 있습니다. 따라서 이전 버전의 SQL Server에서 업그레이드된 데이터베이스에서 DATA_PURITY 옵션을 사용해 DBCC CHECKDB를 실행하면 기존의 열 값 오류가 드러날 수 있습니다. SQL Server 2005는 이 오류를 자동으로 복구할 수 없기 때문에 열 값은 수동으로 업데이트해야 합니다. CHECKDB는 이러한 오류를 검색하면 경고 및 오류 번호 2570, 그리고 영향을 받은 행을 식별하고 수동으로 오류를 수정하기 위한 정보를 반환합니다.

복구 작업은 사용자가 변경 내용을 롤백할 수 있도록 사용자 트랜잭션 내에서 수행할 수 있습니다. 복구가 롤백되어도 데이터베이스에는 오류가 그대로 포함되어 있으므로 백업에서 데이터베이스를 복원해야 합니다. 복구를 완료한 후 데이터베이스를 백업하십시오.

데이터베이스 응급 모드로 오류 해결

ALTER DATABASE 문을 사용하여 데이터베이스가 응급 모드로 설정된 경우 REPAIR_ALLOW_DATA_LOSS 옵션을 지정하면 DBCC CHECKDB는 데이터베이스에 대해 특별한 복구 작업을 수행할 수 있습니다. 이러한 복구 작업을 사용하면 일반적으로 복구 불가능한 데이터베이스가 물리적으로 일관된 상태로 다시 온라인 상태가 될 수 있습니다. 백업에서 데이터베이스를 복원할 수 없는 경우에만 최후의 수단으로 이러한 복구 작업을 사용해야 합니다. 데이터베이스를 응급 모드로 설정하면 데이터베이스가 READ_ONLY로 표시되며 로깅 설정이 해제되고 액세스가 sysadmin 고정 서버 역할의 멤버로 제한됩니다.

[!참고] 사용자 트랜잭션 내부에서 응급 모드로 DBCC CHECKDB 명령을 실행하고 실행 후에 트랜잭션을 롤백할 수는 없습니다.

데이터베이스가 응급 모드에 있고 REPAIR_ALLOW_DATA_LOSS 절이 있는 DBCC CHECKDB를 실행하면 다음 작업이 수행됩니다.

• DBCC CHECKDB는 I/O 또는 체크섬 오류로 인해 액세스가 불가능하다고 표시된 페이지를 오류가 발생하지 않은 것처럼 사용합니다. 이렇게 할 경우 데이터베이스의 데이터 복구 기회가 많아집니다.
• DBCC CHECKDB는 일반적인 로그 기반의 복구 기술을 사용하여 데이터베이스 복구를 시도합니다.
• 트랜잭션 로그 손상으로 인해 데이터베이스 복구가 실패하면 트랜잭션 로그가 다시 작성됩니다. 트랜잭션 로그를 다시 작성하면 트랜잭션 일관성을 유지할 수 없습니다.

DBCC CHECKDB 명령이 성공하면 데이터베이스는 물리적으로 일관된 상태가 되며 데이터베이스 상태가 ONLINE으로 설정됩니다. 그러나 데이터베이스에 하나 이상의 트랜잭션 불일치가 포함되어 있을 수 있습니다. DBCC CHECKCONSTRAINTS를 실행하여 비즈니스 논리 결함을 식별하고 즉시 데이터베이스를 백업하는 것이 좋습니다.

DBCC CHECKDB 명령이 실패하면 데이터베이스를 복구할 수 없습니다.

복제된 데이터베이스에서 REPAIR_ALLOW_DATA_LOSS 옵션으로 DBCC CHECKDB 실행

REPAIR_ALLOW_DATA_LOSS 옵션으로 DBCC CHECKDB 명령을 실행하면 사용자 데이터베이스(게시 및 구독 데이터베이스)와 복제에 사용되는 배포 데이터베이스에 영향을 줄 수 있습니다. 게시 및 구독 데이터베이스에는 게시된 테이블과 복제 메타데이터 테이블이 포함됩니다. 이러한 데이터베이스에서 발생 가능한 다음 문제에 주의하십시오.

• 게시된 테이블. 손상된 사용자 데이터를 복구하기 위해 CHECKDB 프로세스에서 수행한 작업이 복제되지 않을 수 있습니다.
  • 병합 복제는 트리거를 사용하여 게시된 테이블의 변경 내용을 추적합니다. CHECKDB 프로세스에서 행을 삽입, 업데이트 또는 삭제하면 트리거가 발생하지 않으므로 변경 내용이 복제되지 않습니다.
  • 트랜잭션 복제는 트랜잭션 로그를 사용하여 게시된 테이블의 변경 내용을 추적합니다. 그런 다음 로그 판독기 에이전트가 이러한 변경 내용을 배포 데이터베이스로 이동합니다. 일부 DBCC 복구는 기록만 되고 로그 판독기 에이전트에서 복제할 수 없습니다. 예를 들어 CHECKDB 프로세스에서 데이터 페이지를 할당 취소한 경우 로그 판독기 에이전트가 이를 DELETE 문으로 변환하지 않으므로 변경 내용이 복제되지 않습니다.
• 복제 메타데이터 테이블. 손상된 복제 메타데이터 테이블을 복구하기 위해 CHECKDB 프로세스에서 수행한 작업 때문에 복제를 제거하고 다시 구성해야 합니다.

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

1. 시스템을 정지합니다. 해당 데이터베이스와 복제 토폴로지에 있는 다른 모든 데이터베이스에서 작업을 중지하고 모든 노드를 동기화합니다. 자세한 내용은 How to: Quiesce a Replication Topology (Replication Transact-SQL Programming)를 참조하십시오.
2. DBCC CHECKDB를 실행합니다.
3. DBCC CHECKDB 보고서에 배포 데이터베이스의 테이블이나 사용자 데이터베이스의 복제 메타데이터 테이블에 대한 복구가 포함되어 있으면 복제를 제거하고 다시 구성합니다. 자세한 내용은 복제 제거를 참조하십시오.
4. DBCC CHECKDB 보고서에 복제된 테이블에 대한 복구가 포함되어 있으면 데이터 유효성 검사를 통해 복제 데이터베이스와 구독 데이터베이스의 데이터가 서로 다른지 확인합니다. 자세한 내용은 게시자와 구독자의 데이터가 일치하지 않음을 참조하십시오.

사용 권한

sysadmin 고정 서버 역할의 멤버 또는 db_owner 고정 데이터베이스 역할의 멤버여야 합니다.

예

1. 현재 데이터베이스와 AdventureWorks 데이터베이스 모두 검사

다음 예에서는 현재 데이터베이스 및 AdventureWorks 데이터베이스에 대해 DBCC CHECKDB를 실행합니다.

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

2. 현재 데이터베이스 검사 후 정보 메시지를 표시하지 않음

다음 예에서는 현재 데이터베이스를 검사하되 모든 정보 메시지를 표시하지 않습니다.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

참고 항목

참조

DBCC(Transact-SQL)
sp_helpdb(Transact-SQL)
시스템 테이블(Transact-SQL)

관련 자료

물리적 데이터베이스 아키텍처
데이터베이스 스냅숏의 스파스 파일 크기 이해
인덱싱된 뷰의 DBCC 오류 문제 해결
DBCC CHECKDB 성능 최적화

도움말 및 정보

SQL Server 2005 지원 받기

변경 내역