DBCC CHECKDB에서 보고된 데이터베이스 일관성 오류 문제 해결

이 문서에서는 명령에서 보고한 DBCC CHECKDB 오류를 해결하는 방법을 설명합니다.

원래 제품 버전: SQL Server
원래 KB 번호: 2015748

증상

DBCC CHECKDB(또는 DBCC CHECKTABLE과 같은 다른 유사한 명령)가 실행되면 다음과 같은 메시지가 SQL Server 오류 로그에 기록됩니다.

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

이 메시지는 복구 옵션을 사용한 경우 발견된 데이터베이스 일관성 오류 수와 복구된 오류 수를 보여 줍니다. 또한 이 메시지는 EventID=8957을 사용하여 Windows 애플리케이션 이벤트 로그에 정보 수준 메시지로 기록됩니다. 오류가 보고되더라도 이 메시지는 정보 수준 메시지입니다.

"내부 데이터베이스 스냅샷..."으로 시작하는 메시지의 정보입니다. 은 데이터베이스가 모드에 없는 SINGLE_USER 온라인으로 실행된 경우에만 DBCC CHECKDB 나타납니다. 온라인 DBCC CHECKDB의 경우 내부 데이터베이스 스냅샷을 사용하여 확인할 일관된 데이터 집합을 표시하기 때문입니다.

이 문서에서는 보고한 각 특정 오류를 해결하는 방법을 설명하는 것이 아니라 오류가 보고 DBCC CHECKDB 되는 경우 일반적인 방법을 설명합니다. 이 문서의 참조 CHECKDB 는 명시되지 않은 한 DBCC CHECKFILEGROUP에도 적용됩니다 DBCC CHECKTABLE .

원인

이 DBCC CHECKDB 명령은 데이터베이스 페이지, 행, 할당 페이지, 인덱스 관계, 시스템 테이블 참조 무결성 및 기타 구조 검사의 물리적 및 논리적 일관성을 확인합니다. 선택한 옵션에 따라 이러한 검사가 실패하면 오류가 보고됩니다.

이러한 문제의 원인은 파일 시스템 손상, 기본 하드웨어 시스템 문제, 드라이버 문제, 메모리 또는 스토리지 캐시의 손상된 페이지 또는 SQL Server 관련 문제에서 비롯될 수 있습니다. 보고된 오류의 근본 원인을 식별하는 방법에 대한 자세한 내용은 근본 원인 조사를 참조하세요.

해결

1. 백업 복원 또는 데이터베이스 복구를 계속하기 전에 시스템의 기본 하드웨어 관련 문제를 해결합니다. I/O 경로와 관련된 모든 디바이스 드라이버, 펌웨어, BIOS 및 운영 체제 업데이트를 적용합니다. 전체 I/O 경로(로컬 컴퓨터, 디바이스 드라이버, 스토리지 NIC, SAN, 백 엔드 스토리지 및 캐시)의 관리자와 협력하여 문제를 격리하고 해결합니다. 예를 들어 디바이스 드라이버를 업데이트하고 전체 I/O 경로의 구성을 확인하는 것이 있습니다. 근본 원인을 확인하는 방법에 대한 자세한 내용은 근본 원인 조사를 참조하세요.

2. 영구 일관성 오류를 보고하는 경우 DBCC CHECKDB 가장 좋은 해결 방법은 알려진 정상 백업에서 데이터를 복원하는 것입니다. 자세한 내용은 복원 및 복구를 참조 하세요.

3. 최신 SQL Server 누적 업데이트 또는 서비스 팩을 적용하여 알려진 문제가 발생하지 않도록 합니다. 누적 업데이트 또는 서비스 팩 설명서에서 데이터베이스 손상(일관성 오류)과 관련하여 해결된 알려진 문제를 확인하고 관련 수정 사항을 적용합니다. SQL Server 2022, 2019, 2017에 대한 자세한 수정 사항이 나열된 경우 특정 버전에 대한 모든 수정 사항을 검색할 수 있는 중앙 위치 중 하나입니다.

4. DBCC CHECKDB 오류가 간헐적인 경우 즉, 한 실행에서 나타나고 다음 실행에서 사라지는 경우 디스크 캐시 문제(디바이스 드라이버 또는 다른 I/O 경로 문제)가 발생할 수 있습니다. I/O 경로의 유지 관리자와 협력하여 문제를 격리하고 해결합니다. 예를 들어 디바이스 드라이버 업데이트, 전체 I/O 경로의 구성 확인, I/O 경로 디바이스 및 시스템에서 펌웨어 및 BIOS 업데이트 등이 있습니다.

5. 백업 CHECKDB 에서 복원할 수 없는 경우 사용할 수 있는 오류를 복구하는 기능이 있습니다. 다음과 같은 두 가지 수준의 복구가 있습니다.

   • REPAIR_REBUILD - 데이터 손실 가능성이 없는 복구를 수행합니다.
   • REPAIR_ALLOW_DATA_LOSS - 데이터 손실 가능성이 있는 복구를 수행합니다.

   자세한 내용은 DBCC CHECKDB 설명서를 참조 하세요.

   데이터베이스가 논리적으로 일관되지 않은 상태로 남을 수 있으므로 데이터 손실 허용으로 복구를 선택할 때 주의해야 합니다. 출력은 DBCC CHECKDB 사용할 최소 복구 수준에 대한 권장 사항을 만듭니다. 더 이상 오류가 보고되지 않을 때까지 여러 번 실행하는 CHECKDB REPAIR_ALLOW_DATA_LOSS 것이 일반적입니다. 복구에서 오류 집합을 수정하면 다른 끊어진 링크가 발견될 수 있기 때문입니다. 그러나 근본 원인을 해결하지 못한 경우 새 오류가 표시될 수 있습니다. 따라서 하드웨어 또는 파일 시스템과 같은 시스템 수준 문제로 인해 데이터가 손상되는 경우 백업 또는 복구를 복원하기 전에 먼저 이러한 문제를 해결해야 합니다. Microsoft 지원 엔지니어는 복구에서 일관성 오류를 수정하지 않거나 데이터베이스 백업이 손상된 경우 손상된 데이터의 물리적 복구를 지원할 수 없습니다.

   실행할 DBCC CHECKDB때 모든 오류를 복구하는 데 필요한 최소 복구 옵션을 나타내는 권장 사항이 제공됩니다. 이러한 메시지는 다음 출력과 유사합니다.

   CHECKDB는 데이터베이스 'mydb'에서 0개 할당 오류 및 15개 일관성 오류를 발견했습니다.
   REPAIR_ALLOW_DATA_LOSS 는 (mydb)에서 찾은 DBCC CHECKDB 오류에 대한 최소 복구 수준입니다.

   복구 권장 사항은 모든 오류를 CHECKDB해결하기 위한 최소 복구 수준입니다. 최소 복구 수준이 이 복구 옵션이 모든 오류를 수정한다는 의미는 아닙니다. 일부 오류는 단순히 해결할 수 없습니다. 또한 복구 프로세스를 두 번 이상 실행해야 할 수도 있습니다. 보고된 모든 오류를 해결하려면 이 복구 수준을 사용해야 하는 것은 아닙니다. 즉, 데이터 손실로 인해 모든 복구가 CHECKDB REPAIR_ALLOW_DATA_LOSS 수행되는 것은 아닙니다. 오류 해결로 인해 데이터가 손실되는지 확인하려면 복구를 실행해야 합니다. 각 테이블에 대한 복구 수준을 좁히는 데 도움이 되는 한 가지 방법은 오류를 보고하는 테이블에 사용하는 DBCC CHECKTABLE 것입니다. 지정된 테이블에 대한 최소 복구 수준을 보여줍니다.

   Warning

   복구 또는 데이터 내보내기 또는 가져오기가 완료된 후 CHECKDB 수동 데이터 유효성 검사를 수행해야 합니다. 자세한 내용은 DBCC CHECKDB 인수를 참조 하세요. 복구 후 데이터가 논리적으로 일관되지 않을 수 있습니다. 예를 들어 복구(특히 REPAIR_ALLOW_DATA_LOSS 옵션)는 일관되지 않은 데이터가 포함된 전체 데이터 페이지를 제거할 수 있습니다. 이러한 경우 다른 테이블과 외래 키 관계가 있는 테이블은 상위 테이블에 해당 기본 키 행이 없는 행으로 끝날 수 있습니다.

6. 데이터베이스 스키마를 스크립아웃해 봅니다. 스크립트를 사용하여 새 데이터베이스를 만든 다음 BCP 또는 SSIS 내보내기/가져오기 마법사와 같은 도구를 사용하여 손상된 데이터베이스에서 새 데이터베이스로 최대한 많은 데이터를 내보냅니다. 손상된 테이블에서 데이터를 내보내지 못할 수 있습니다. 이러한 경우 이 테이블을 건너뛰고 다음으로 이동한 다음 할 수 있는 것을 저장합니다.

7. 다음 문서에서 생성된 DBCC CHECKDB 특정 오류를 검토하고 제공된 단계(있는 경우)를 따릅니다. 다음 몇 가지 예를 참조하세요.

   • 오류 605(MSSQLSERVER_605)
   • 오류 823(MSSQLSERVER_823)
   • 오류 824(MSSQLSERVER_824)
   • 오류 825(MSSQLSERVER_825)
   • 오류 2508(MSSQLSERVER_2508)
   • 오류 2511(MSSQLSERVER_2511)
   • 오류 2512(MSSQLSERVER_2512)
   • 오류 7987(MSSQLSERVER_7987)
   • 오류 7988(MSSQLSERVER_7988)
   • 오류 7995(MSSQLSERVER_7995)
   • 오류 8993(MSSQLSERVER_8993)
   • 오류 8994(MSSQLSERVER_8994)
   • 오류 8996(MSSQLSERVER_8996)

데이터베이스 일관성 오류의 근본 원인 조사

데이터베이스 일관성 오류의 근본 원인을 식별하려면 다음 방법을 고려합니다.

• Windows 시스템 이벤트 로그에서 시스템 수준, 드라이버 또는 디스크 관련 오류를 확인하고 하드웨어 제조업체와 협력하여 문제를 해결합니다.
• 컴퓨터 및/또는 디스크 시스템에 대해 하드웨어 제조업체에서 제공하는 모든 진단을 실행합니다.
• 하드웨어 공급업체 또는 디바이스 제조업체와 협력하여 다음을 확인합니다.
  • 하드웨어 디바이스 및 구성은 Microsoft SQL Server 데이터베이스 엔진 입력/출력 요구 사항을 확인합니다.
  • I/O 경로에 있는 모든 디바이스의 디바이스 드라이버 및 기타 지원 소프트웨어 구성 요소가 최신 상태입니다.
• 일관성 오류를 보고한 데이터베이스가 있는 드라이브에서 SQLIOSim과 같은 유틸리티를 사용하는 것이 좋습니다. SQLIOSim은 디스크 시스템에 대한 I/O의 무결성을 테스트하는 SQL Server 엔진과 독립적인 도구입니다. SQLIOSim은 SQL Server와 함께 사용되며 별도의 다운로드가 필요하지 않습니다. \MSSQL\Binn 폴더에서 찾을 수 있습니다.
• 누적 업데이트 또는 서비스 팩 설명서에서 데이터베이스 손상(일관성 오류)과 관련하여 해결된 알려진 문제를 확인하고 관련 수정 사항을 적용합니다. SQL Server 2022, 2019, 2017에 대한 자세한 수정 사항이 나열된 경우 특정 버전에 대한 모든 수정 사항을 검색할 수 있는 중앙 위치 중 하나입니다.
• 액세스 위반 또는 어설션과 같은 SQL Server에서 보고한 다른 오류를 확인합니다. 손상된 데이터베이스에 대한 활동으로 인해 액세스 위반 예외 또는 어설션 오류가 자주 발생합니다.
• 데이터베이스에서 이 옵션을 사용하고 PAGE_VERIFY CHECKSUM 있는지 확인합니다. 체크섬 오류가 보고되는 경우 SQL Server가 디스크에 페이지를 쓴 후 일관성 오류가 발생했음을 나타냅니다. 따라서 I/O 하위 시스템을 철저히 확인해야 합니다. 체크섬 오류에 대한 자세한 내용은 SQL Server에서 Msg 824 문제를 해결하는 방법을 참조 하세요.
• ERRORLOG에서 메시지 832 오류를 찾습니다. 이러한 오류는 디스크에 기록하기 전에 페이지가 캐시에 있는 동안 손상되었을 수 있음을 나타낼 수 있습니다. 자세한 내용은 SQL Server에서 Msg 832 문제를 해결하는 방법을 참조 하세요.
• 다른 시스템에서는 "정리"(오류 없음)인 데이터베이스 백업과 오류가 CHECKDB생성된 시간에 걸친 트랜잭션 로그 백업을 복원해 봅니다. "클린" 데이터베이스 백업 및 트랜잭션 로그 백업을 복원하여 이 문제를 "다시 만들"수 있는 경우 Microsoft 기술 지원에 문의하세요.
• 데이터 순도 오류는 애플리케이션이 SQL Server 테이블에 잘못된 데이터를 삽입하거나 업데이트하는 데 문제가 될 수 있습니다. 데이터 순도 오류 문제 해결에 대한 자세한 내용은 SQL Server 2005에서 DBCC 오류 2570 문제 해결을 참조하세요.
• chkdsk 명령을 사용하여 파일 시스템의 무결성을 확인합니다. SQL Server가 실행되는 동안에는 실행 chkdsk 하지 마세요. SQL Server가 검사 중인 파일에 쓰는 경우 일시적인 파일 오류를 보고할 수 있습니다. 또한 파일 바이트를 디스크의 다른 위치로 이동하거나 /f 같은 /r 스위치로 전환하면 SQL Server가 이러한 파일에 쓰거나 읽는 경우 이러한 이동이 손상될 수 있습니다. 따라서 명령을 실행하기 전에 SQL Server를 chkdsk 중지해야 합니다. 또한 다음과 같은 /r /f복구 옵션에 주의해야 합니다. 디스크 오류가 발견되면 이러한 옵션이 파일을 손상시킬 수 있으므로 복구를 실행하기 전에 데이터베이스 백업이 chkdsk있는지 확인합니다.

자세한 정보

명령의 구문 DBCC CHECKDB 및 명령 실행 방법에 대한 정보 또는 옵션에 대한 자세한 내용은 DBCC CHECKDB(Transact-SQL)를 참조하세요.

사용 CHECKDB으로 오류가 발견되면 오류 보고를 위해 다음 메시지와 유사한 다른 메시지가 ERRORLOG에 보고됩니다.

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

오류 정보가 Watson 오류 보고에 제출되었습니다.

오류 보고에 사용되는 파일에는 SQLDump<nnn>.txt 파일이 포함됩니다. 이 파일은 XML 형식에서 찾 CHECKDB 은 오류 목록을 포함하기 때문에 기록 용도로 유용할 수 있습니다.

데이터베이스에 대한 오류 검색 없이 마지막으로 실행된 시간을 DBCC CHECKDB 확인하려면(마지막으로 알려진 정리 CHECKDB) SQL Server ERRORLOG를 확인합니다. 사용자 또는 시스템 데이터베이스에 대해 다음과 같은 메시지를 찾습니다. 이 메시지는 EventID = 17573이 포함된 Windows 애플리케이션 이벤트 로그에서 정보 수준 메시지로 작성됩니다.

데이터베이스 'master'에 대한 날짜/시간 spid7s CHECKDB가 날짜/시간22:11:11.417(현지 시간)에 오류 없이 완료되었습니다. 정보 메시지일 뿐입니다. 사용자 작업이 필요하지 않음