DBCC CHECKTABLE(Transact-SQL)

업데이트: 2008년 11월 17일

테이블 또는 인덱싱된 뷰를 구성하는 모든 페이지 및 구조의 무결성을 검사합니다.

Transact-SQL 구문 표기 규칙

구문

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , NO_INFOMSGS ]
          [ , TABLOCK ] 
          [ , ESTIMATEONLY ] 
          [ , { PHYSICAL_ONLY | DATA_PURITY } ] 
        }
    ]

인수

• table_name | view_name
  무결성 검사를 실행할 테이블 또는 인덱싱된 뷰입니다. 테이블 또는 뷰 이름은 식별자에 대한 규칙을 따라야 합니다.

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

• index_id
  무결성 검사를 실행할 인덱스 ID 번호입니다. index_id를 지정하면 DBCC CHECKTABLE은 힙 또는 클러스터형 인덱스와 함께 해당 인덱스에 대해서만 무결성 검사를 실행합니다.

• REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
  DBCC CHECKTABLE 실행 시 발견된 오류를 복구하도록 지정합니다. 복구 옵션을 사용하려면 데이터베이스가 단일 사용자 모드여야 합니다.

  • 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개의 오류 메시지만 표시됩니다.

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

• TABLOCK
  DBCC CHECKTABLE이 내부 데이터베이스 스냅숏 대신 공유 테이블 잠금을 가져오도록 합니다. 테이블의 부하가 큰 상태에서 TABLOCK을 사용하면 DBCC CHECKTABLE의 실행 속도를 빠르게 할 수 있지만 DBCC CHECKTABLE이 실행되는 동안 테이블에서 사용할 수 있는 동시성은 줄어듭니다.

• ESTIMATEONLY
  DBCC CHECKTABLE 실행에 필요한 tempdb 공간의 예상 크기와 지정된 다른 옵션을 모두 표시합니다.

• PHYSICAL_ONLY
  무결성 검사를 페이지의 물리적 구조, B-트리의 물리적 구조 및 레코드 헤더로 제한합니다. 이 검사는 테이블에 대한 물리적 일관성 검사의 오버헤드를 줄이기 위한 목적으로 사용하며 데이터가 손상될 가능성이 있는 조각난 페이지와 일반적인 하드웨어 오류도 찾습니다. SQL Server 2005에서 다음과 같은 원인으로 DBCC CHECKTABLE 전체 실행에 이전 버전에서보다 현저히 더 많은 시간이 걸릴 수 있습니다.

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

  따라서 대형 테이블에서는 PHYSICAL_ONLY 옵션을 사용하여 DBCC CHECKTABLE 실행 시간을 훨씬 단축시킬 수 있으므로 생산 시스템에서의 잦은 검사 작업에는 이 옵션을 사용하는 것이 좋습니다. 하지만 정기적으로 DBCC CHECKTABLE 전체 실행을 수행하는 것이 좋습니다. 이러한 실행 빈도는 개별 비즈니스 및 프로덕션 환경과 관련된 여러 가지 요소에 따라 달라집니다. PHYSICAL_ONLY는 항상 NO_INFOMSGS를 의미하며 어떠한 복구 옵션과도 함께 사용할 수 없습니다.

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

  SQL Server 2005에서 생성된 데이터베이스의 경우 기본적으로 열 값 무결성 검사가 사용되며 DATA_PURITY 옵션은 필요하지 않습니다. 이전 버전의 SQL Server에서 업그레이드한 데이터베이스의 경우에는 DBCC CHECKTABLE WITH DATA_PURITY를 사용하여 특정 테이블의 오류를 찾고 수정할 수 있지만 DBCC CHECKDB WITH DATA_PURITY가 데이터베이스에서 오류 없이 실행되기 전까지는 테이블의 열 값 검사를 기본적으로 사용하지 않습니다. 이 옵션이 성공적으로 실행되면 DBCC CHECKDB 및 DBCC CHECKTABLE은 기본적으로 열 값 무결성을 검사합니다.

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

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

결과 집합

DBCC CHECKTABLE은 다음 결과 집합을 반환합니다. 테이블 이름만 지정하거나 아무 옵션도 지정하지 않은 경우 동일한 결과 집합이 반환됩니다.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

ESTIMATEONLY 옵션이 지정된 경우 DBCC CHECKTABLE은 다음 결과 집합을 반환합니다.

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

주의

DBCC CHECKTABLE은 NOINDEX 옵션이 지정되지 않으면 단일 테이블 또는 인덱싱된 뷰 및 모든 비클러스터형 XML 인덱스에서 일관성 검사를 수행합니다. 데이터베이스의 모든 테이블에서 DBCC CHECKTABLE을 수행하려면 DBCC CHECKDB를 사용합니다.

DBCC CHECKTABLE은 지정한 테이블에 대해 다음 사항을 검사합니다.

• 인덱스, 행 내부, LOB 및 행 오버플로 데이터 페이지가 올바로 연결되어 있습니다.
• 인덱스 정렬 순서가 올바로 되어 있습니다.
• 포인터가 일관성이 있습니다.
• 각 페이지의 데이터가 적절하며 계산 열을 포함합니다.
• 페이지 오프셋이 적절합니다.
• 기본 테이블의 모든 행에는 각 비클러스터형 인덱스에 일치하는 행이 있으며 반대의 경우도 마찬가지입니다.
• 분할된 테이블 또는 인덱스의 모든 행이 올바른 파티션에 있습니다.

내부 데이터베이스 스냅숏

DBCC CHECKTABLE은 이러한 검사를 수행하기 위해 확보해야 하는 트랜잭션 일관성을 제공하기 위해 내부 데이터베이스 스냅숏을 사용합니다. 자세한 내용은 데이터베이스 스냅숏의 스파스 파일 크기 이해 및 DBCC(Transact-SQL)의 "DBCC 내부 데이터베이스 스냅숏 사용법" 섹션을 참조하십시오.

스냅숏을 만들 수 없거나 TABLOCK이 지정된 경우 DBCC CHECKTABLE은 공유 테이블 잠금을 획득하여 필요한 일관성을 확보합니다.

[!참고] DBCC CHECKTABLE이 tempdb에 대해 실행되는 경우 공유 테이블 잠금을 반드시 획득해야 합니다. 이것은 성능상의 이유로 tempdb에 대해 데이터베이스 스냅숏을 사용할 수 없기 때문입니다. 즉, 필요한 트랜잭션 일관성을 얻을 수 없음을 의미합니다.

병렬로 개체 검사

기본적으로 DBCC CHECKTABLE은 개체의 병렬 검사를 수행합니다. 병렬 처리 수준은 쿼리 프로세서에 의해 자동으로 결정됩니다. 최대 병렬 처리 수준은 최대 병렬 쿼리 수준과 동일한 방식으로 구성됩니다. DBCC 검사에 사용할 수 있는 최대 프로세서 수를 제한하려면 sp_configure를 사용합니다. 자세한 내용은 max degree of parallelism 옵션을 참조하십시오.

추적 플래그 2528을 사용하면 병렬 검사를 비활성화할 수 있습니다. 자세한 내용은 추적 플래그(Transact-SQL)를 참조하십시오.

[!참고] DBCC CHECKTABLE 작업 중에 바이트 정렬 사용자 정의 유형 열에 저장된 바이트는 사용자 정의 유형 값의 계산된 직렬화 결과와 같아야 합니다. 그렇지 않으면 DBCC CHECKTABLE 루틴에서 일관성 오류를 보고합니다.

DBCC 오류 메시지 이해

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

오류 보고

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

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

오류 해결

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

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

사용 권한

사용자가 테이블을 소유하거나 sysadmin 고정 서버 역할, db_owner 고정 데이터베이스 역할 또는 db_ddladmin 고정 데이터베이스 역할의 멤버여야 합니다.

예

1. 특정 테이블 검사

다음 예에서는 AdventureWorks 데이터베이스의 HumanResources.Employee 테이블에 대한 데이터 페이지 무결성을 검사합니다.

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

2. 테이블에 오버헤드가 적은 검사 수행

다음 예에서는 AdventureWorks 데이터베이스의 Employee 테이블에 오버헤드가 적은 검사를 수행합니다.

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

3. 특정 인덱스 검사

다음 예에서는 sys.indexes에 액세스하여 얻은 특정 인덱스를 검사합니다.

USE AdventureWorks;
GO
DECLARE @indid int;
SET @indid = (SELECT index_id 
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ("Production.Product", @indid);

참고 항목

참조

DBCC(Transact-SQL)

관련 자료

테이블 및 인덱스 아키텍처
인덱싱된 뷰의 DBCC 오류 문제 해결

도움말 및 정보

SQL Server 2005 지원 받기

변경 내역