DBCC CHECKDB: MS에 대한 완벽한 가이드 SQL Server 데이터베이스 상태(2025)

데이터베이스 손상은 모든 SQL Server 관리자의 악몽. 중요한 비즈니스 데이터에 접근할 수 없거나 신뢰할 수 없게 되면,ost 치명적일 수 있습니다. 이 종합 가이드에서는 DBCC CHECKDB를 사용하여 데이터베이스 상태를 유지하고 손상을 방지하는 데 필요한 모든 정보와 표준 도구로는 충분하지 않을 때를 위한 고급 복구 솔루션에 대해 다룹니다.

1. 중요성 SQL Server 데이터베이스 상태

1.1 데이터베이스 손상 Costs 사업체

오늘은 most 기업은 중요 데이터를 데이터베이스에 저장합니다. 데이터베이스 손상이 발생하면 그 결과는 매우 심각합니다.

• 재정적 손실 하드웨어 오류 및 손상이 주요 원인으로 데이터 손실로 인해 연간 평균 2.3만 달러의 손실이 발생합니다(EMC Corporation).
• 사업 폐쇄율 하드웨어 장애로 인해 데이터 손실을 경험한 중소기업의 50%가 94년 이내에 사업을 중단하는 반면, 심각한 데이터 손실을 경험한 기업의 XNUMX%는 전혀 살아남지 못한다는 사실을 보여줍니다.
• 데이터 손상 빈도 매년 미션 크리티컬 애플리케이션의 20%에 영향을 미쳐 비즈니스 연속성 중단을 초래합니다(Gartner 연구)
• 하드웨어 관련 부패 하드 드라이브 충돌 및 시스템 오류로 인한 모든 데이터 손실 사고의 67%를 차지하며, 데이터 손실의 40%는 하드웨어 오작동에 직접적으로 기인합니다.
• 소프트웨어 손상 costs 심각도와 범위에 따라 수천 달러에서 수백만 달러에 달하며, 기업의 82%가 부패가 주요 원인인 계획되지 않은 중단을 경험했습니다.

1.2 정기 건강 검진이 중요한 이유

사람들은 잠재적인 질병을 조기에 발견하기 위해 정기적인 건강 검진이 필요합니다. 마찬가지로, 데이터베이스도 정기적인 건강 검진이 필요합니다.

1. 잠재적인 부패를 일찍 발견하고 신속하게 처리하면 문제가 심각하고 광범위하게 확대되어 기업에 치명적인 결과를 초래하는 것을 예방할 수 있습니다.
2. 데이터베이스가 최적의 성능으로 작동하는지 확인하세요.
3. Cost 사전 예방적 데이터베이스 상태 점검의 비율은 데이터베이스 재해 발생 후 사후 대응적 데이터 복구의 비율보다 훨씬 낮습니다.

1.3 데이터베이스 무결성 명령 소개

SQL Server 데이터베이스 상태를 유지하기 위한 여러 가지 내장 명령을 제공합니다. DBCC 체크DB m으로 봉사하다ost 포괄적인 무결성 검사 도구를 사용할 수 있습니다. 이러한 명령은 개별 테이블부터 전체 데이터베이스 일관성에 이르기까지 데이터베이스 구조의 다양한 측면을 검증하는 데 함께 작동하여 데이터를 안전하게 유지하고 접근성을 유지하는 완벽한 유지 관리 전략을 구축합니다.

2. DBCC CHECKDB란 무엇인가요?

DBCC 체크DB is SQL Server데이터베이스 무결성을 검증하고 손상 문제를 식별하기 위한 주요 도구입니다.

• 이는 GUI 도구가 아니라 T-SQL 명령문입니다.
• 다음과 같은 일반적인 방법을 통해 실행할 수 있습니다. SQL Server 관리 스튜디오(SSMS), SQL Server 에이전트, SQLCMD 등

2.1 CHECKDB가 실제로 데이터베이스에서 확인하는 내용

DBCC CHECKDB를 실행하면 해당 명령은 데이터베이스 구조 전반에 걸쳐 여러 검증 계층을 수행합니다.

• 페이지 체크섬 검증 물리적 손상 및 하드웨어 관련 문제를 감지합니다.
• 인덱스 일관성 검증 적절한 데이터 검색 및 쿼리 성능을 보장하기 위해
• 할당 구조 검사 정확한 공간 사용 및 페이지 할당을 확인하려면
• 참조 무결성 검사 관련 테이블과 외래 키 관계 간
• 시스템 테이블 일관성 검증 보장하기 위해 SQL Server내부 메타데이터는 안정적으로 유지됩니다.
• 데이터 페이지 연결 검증 적절한 페이지 체인 무결성을 확인하려면
• 데이터베이스 스키마 일관성 객체 정의 및 종속성을 검증하려면

이러한 포괄적인 검사는 사용자 데이터와 시스템 구조를 모두 포괄하여 데이터베이스 상태에 대한 완벽한 가시성을 제공합니다.

3. DBCC CHECKDB 실행: 단계별

3.1 선수 조건

DBCC CHECKDB 작업을 실행하기 전에 확인해야 할 사항은 다음과 같습니다.

• 전체 데이터베이스 백업 – 손상이 발견되거나 복구 작업이 필요한 경우를 대비해 무결성 검사를 실행하기 전에 전체 백업을 만들어 두세요.
• 적절한 권한 – DBCC CHECKDB 명령을 실행하려면 sysadmin 또는 db_owner 권한이 필요합니다.
• 충분한 시스템 리소스:
  • 메모리: 데이터베이스 크기의 25%
  • Tempdb 공간: 데이터베이스 크기의 10-15%
  • CPU: 유지 관리 중 가용성 50-70%
  • I/O: 대량 읽기 작업이 예상됩니다.
• 데이터베이스 접근성 – CHECKDB는 모든 데이터베이스 페이지에 대한 읽기 액세스가 필요하므로 데이터베이스가 액세스 가능하고 제한된 상태가 아닌지 확인하십시오.

3.2 기본 명령

most 기본 DBCC CHECKDB 명령에는 세 가지 일반적인 변형이 있습니다.

(1) 현재 데이터베이스 확인(매개변수 없음):

DBCC CHECKDB

(2) 이름으로 데이터베이스 확인:

DBCC CHECKDB ('YourDatabaseName')

(3) ID로 데이터베이스 확인:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

이 기본 명령은 지정된 데이터베이스의 모든 테이블, 인덱스 및 시스템 구조를 검사하여 완전한 무결성 검사를 수행합니다. 공백이 없는 표준 이름을 가진 데이터베이스의 경우 따옴표를 생략할 수 있습니다. 이 명령은 완료될 때까지 실행되며 진행률 메시지와 최종 결과를 표시합니다. 이 기본 구문은 소규모 데이터베이스나 유지 관리 시간이 충분할 때 매우 유용합니다.

아래는 DBCC CHECKDB를 실행하는 스크린샷입니다. SQL Server 관리 스튜디오(SSMS):

3.3 전체 옵션

DBCC CHECKDB에 대한 전체 옵션은 다음과 같습니다.

카테고리	선택권	상품 설명	DBCC CHECKDB 예제
수리 옵션	REPAIR_REBUILD	데이터 손실 없이 복구(예: 인덱스 재구성)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	수리 불가. 하위 호환성만 가능	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	모든 오류를 복구합니다(데이터 손실이 발생할 수 있음)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
범위 통제	NOINDEX	비클러스터형 인덱스 검사를 건너뜁니다.	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	물리적 저장소 무결성(페이지/레코드)만 검사합니다.	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	논리적 열 값 오류(예: 잘못된 날짜)를 확인합니다.	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	심층적인 논리적 검사(인덱싱된 뷰, XML/공간 인덱스)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
출력 제어	ALL_ERRORMSGS	모든 오류를 표시합니다(기본값: 개체당 200개)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	정보 메시지를 숨깁니다	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
성능	TABLOCK	테이블 잠금을 사용합니다(TempDB 사용량은 줄지만 쓰기는 차단됨)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	병렬 처리 설정을 재정의합니다.	DBCC CHECKDB ('MyDB', MAXDOP = 2)
유틸리티	ESTIMATEONLY	필요한 TempDB 공간을 추정합니다. (실제 확인은 하지 않음)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. 결과 이해하기

DBCC CHECKDB는 실행이 성공적으로 완료되었는지 여부에 따라 다른 결과를 생성합니다. 자세히 설명해 보겠습니다.

4.1 CHECKDB 실행이 성공적으로 완료됨

DBCC CHECKDB 실행이 성공적으로 완료되면 데이터베이스 상태에 따라 다양한 유형의 결과가 보고됩니다.

4.1.1 문제가 발견되지 않았습니다

DBCC CHECKDB에서 문제를 찾지 못하면 다음과 비슷한 출력이 표시됩니다.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

이 결과는 귀하의 데이터베이스가 검사된 모든 구조에서 완벽한 무결성을 유지하고 있음을 나타냅니다.

4.1.2 손상 오류 발견

DBCC CHECKDB가 손상 오류를 감지할 때마다 다음 구조의 오류 메시지를 보고합니다.
심각도 수준 가이드:

• 레벨 16-19 : 사용자가 수정할 수 있는 오류, 종종 사소한 손상
• 레벨 20-24 : 시스템 오류, 즉각적인 주의가 필요한 심각한 손상
• 레벨 25 : 치명적인 오류로 인해 데이터베이스에 접근할 수 없습니다.

일반적인 오류는 다음과 같습니다.

• 페이지 체크섬 실패(메시지 824)
• 할당 오류(메시지 8928)
• 인덱스 일관성 문제(메시지 8964)

메시지 구조를 이해하면 대응 조치의 우선순위를 정하고 적절한 복구 전략을 결정하는 데 도움이 됩니다.

4.1.3 일반적인 정보 및 경고 메시지

모든 DBCC CHECKDB 출력이 심각한 문제를 나타내는 것은 아닙니다. 다음과 같은 정보 및 경고 메시지가 출력될 수도 있습니다.

• 수리 내역서 – 사소한 문제를 해결하기 위한 복구 명령을 제안하는 메시지
• 할당 경고 – 데이터 액세스에 영향을 미치지 않는 공간 할당에 대한 경고
• 성능 권장 사항 – 인덱스 유지 관리 및 최적화에 대한 제안
• 정보 고지 – 즉각적인 조치가 필요하지 않은 일반 상태 메시지

이러한 메시지는 즉각적인 조치가 필요한 심각한 손상과 정기적인 유지 관리 기간 동안 해결할 수 있는 사소한 문제를 구별하는 동시에 귀중한 유지 관리 지침을 제공합니다.

경고 메시지 예:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB 실행 중단

CHECKDB가 다양한 이유로 실행 중에 중단되면 오류 메시지를 보고하고 아래 상태 코드와 함께 오류 로그를 추가합니다.

주 정부	상품 설명
0	오류 번호 8930이 발생했습니다. 이는 메타데이터 손상으로 인해 DBCC 명령이 종료되었음을 나타냅니다.
1	오류 번호 8967이 발생했습니다. 내부 DBCC 오류가 발생했습니다.
2	비상 모드 데이터베이스 복구 중 오류가 발생했습니다.
3	이는 DBCC 명령을 종료시킨 메타데이터 손상을 나타냅니다.
4	어설션 또는 액세스 위반이 감지되었습니다.
5	알 수 없는 오류가 발생하여 DBCC 명령이 종료되었습니다.

오류 메시지 예:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

또는

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

오류 로그 예시:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

이런 경우에는 다음과 같은 대체 고급 옵션을 시도해 볼 수 있습니다. DataNumen SQL Recovery 데이터베이스의 손상을 수정하세요.

5. 손상 오류 수정

5.1 백업 및 복원: 가장 안전한 해결책

DBCC CHECKDB가 손상 오류를 식별하는 경우 깨끗한 백업에서 복원하는 것이 가장 안전하고ost 신뢰할 수 있는 솔루션입니다. 이 접근 방식은 근본적인 손상 원인을 제거하는 동시에 데이터 무결성을 보장합니다. 복원하기 전에 다음을 사용하여 백업 무결성을 확인하십시오. 확인만 복원 명령을 사용하고, 데이터 손실을 최소화하기 위해 특정 시점 복구 옵션을 고려하십시오. 하드웨어 문제나 소프트웨어 버그는 재발 방지를 위해 추가적인 주의가 필요할 수 있으므로, 근본 원인 분석을 위해 손상 세부 정보를 문서화하십시오.

5.2 페이지 수준 손상 솔루션

소규모 데이터 부분에 영향을 미치는 격리된 페이지 손상의 경우 SQL Server Enterprise Edition은 데이터베이스를 완전히 복원하지 않고도 손상된 특정 페이지를 복구하는 페이지 복원 기능을 제공합니다. 이 고급 기술을 사용하려면 전체 복구 모델과 현재 로그 백업이 필요합니다.

단계별 페이지 복원 프로세스:

1. 손상된 페이지를 식별하세요 CHECKDB 오류 메시지(예: 페이지 1:256)
2. 현재 로그 백업을 수행합니다. 최근 거래를 캡처하려면:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. 손상된 페이지 복원 m에서ost 최근 전체 백업:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. 차등 백업 적용 (가능한 경우):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. 모든 로그 백업 적용 순서대로, 방금 만든 것을 포함해서:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. 최종 로그 백업 및 복원 페이지를 최신 상태로 유지하려면:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

비중요 데이터에 대한 대안: 손상으로 인해 중요하지 않은 데이터가 영향을 받는 경우 손상된 구조를 다시 빌드하기 전에 영향을 받지 않은 행을 새 테이블로 내보낼 수 있습니다.

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 인덱스 손상 빠른 수정

인덱스 손상은 기본 테이블 데이터에 영향을 주지 않고 인덱스 구조를 재생성하는 작업을 재구축하는 데 잘 반응하는 경우가 많습니다.

ALTER INDEX ALL ON YourTable REBUILD

이 접근 방식은 클러스터되지 않은 인덱스 손상에 특히 효과적입니다. 인덱스를 재구축하면 원본 테이블 데이터에서 인덱스 페이지가 재생성되어 모든 원본 정보를 보존하면서 손상을 효과적으로 제거할 수 있기 때문입니다.

6. REPAIR_REBUILD 및 REPAIR_ALLOW_DATA_LOSS를 사용하세요.

이전 방법이 모두 실패하거나 실행 불가능한 경우 REPAIR_REBUILD 및 REPAIR_ALLOW_DATA_LOSS 옵션을 사용하여 데이터베이스를 복구할 수 있습니다.

6.1 REPAIR_REBUILD (더 안전한 옵션):

• 사용: 인덱스 손상 및 사소한 할당 오류
• 데이터 안전: 데이터 삭제 없이 손상 수정 시도
• 위험 수준: 낮음 - 데이터 손실이 예상되지 않음
• 일반적인 시나리오: 비클러스터형 인덱스 손상, 사소한 메타데이터 문제
• 명령 예: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS(최후의 수단):

• 사용: 백업이 불가능할 경우 심각한 손상 발생
• 데이터 안전: 손상된 데이터를 삭제하여 데이터베이스 기능을 복원할 수 있습니다.
• 위험 수준: 높음 - 영구적인 데이터 손실 가능
• 일반적인 시나리오: 페이지 손상, 시스템 테이블 손상, 할당 체인 오류
• 명령 예: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 이러한 옵션에 대한 모범 사례:

• 항상 테스트하세요 가능한 경우 데이터베이스 복사본에 대한 복구 작업
• 항상 백업하세요 이러한 옵션을 실행하기 전에
• 모든 변경 사항을 문서화하세요 규정 준수 및 문제 해결 목적
• 데이터베이스를 단일 사용자 모드로 설정 수리 작업을 실행하기 전에

일반적으로 우리는 시도해야 합니다 수리_재구축 먼저 옵션을 선택하세요. 실패하면 시도해 보세요. 수리_ALLOW_DATA_LOSS 옵션을 선택합니다.

6.4 REPAIR_ALLOW_DATA_LOSS 결과

6.4.1 데이터 손실 시 복구 성공

때로는 수리_ALLOW_DATA_LOSS 옵션은 성공하지만 일부 데이터는 l입니다.ost 수리 후.

다음은 몇 가지 샘플 메시지입니다.

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

이는 DBCC CHECKDB가 일부 손상된 레코드를 포기하여 데이터베이스를 수정하기 때문이지만 실제로는ost 그 중 일부는 여전히 다음을 통해 복구할 수 있습니다. DataNumen SQL Recovery.

샘플 파일:

SQL Server 버전	손상된 MDF 파일	MDF 파일 수정 DataNumen SQL Recovery
SQL Server 2014	오류 10_1.mdf (메시지 8909 다음에 메시지 8939가 옵니다) (600개 레코드 lost REPAIR_ALLOW_DATA_LOSS)가 있음	오류10_1_fixed.mdf (기록 없음 lost)
SQL Server 2014	오류 10_2.mdf (메시지 8909 다음에 메시지 8939가 옵니다) (6000개 레코드(50%) lost REPAIR_ALLOW_DATA_LOSS)가 있음	오류10_2_fixed.mdf (단 100개의 레코드만 lost)
SQL Server 2014	Error7의 .mdf (100개 레코드 lost REPAIR_ALLOW_DATA_LOSS)가 있음	오류7_fixed.mdf (단 하나의 기록 lost)

6.4.2 수리 실패 – 전문가 솔루션 고려

If 수리_ALLOW_DATA_LOSS 실패하면 하나 이상의 오류 메시지가 출력됩니다.

다음은 몇 가지 예입니다.

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

이러한 시나리오에서는 다음과 같은 전문 솔루션을 사용해야 합니다. DataNumen SQL Recovery 데이터베이스를 수정하세요.

샘플 파일

SQL Server 버전	손상된 MDF 파일	MDF 파일 수정 DataNumen SQL Recovery
SQL Server 2014	오류 1_3.mdf (단일 메시지 824)	오류1_3_fixed.mdf
SQL Server 2014	오류 1_1.mdf (지속적인 Msg 824 오류)	오류 1_1_고정.mdf
SQL Server 2014	오류 1_2.mdf ((메시지 824 다음에 메시지 7909가 옵니다)	오류1_2_fixed.mdf
SQL Server 2014	오류 4_1.mdf (메시지 8992 다음에 메시지 3852가 옵니다)	오류4_1_fixed.mdf
SQL Server 2014	오류 4_2.mdf (메시지 8992 다음에 메시지 3852가 옵니다)	오류4_2_fixed.mdf
SQL Server 2014	오류5.mdf (메시지 8945)	오류5_fixed.mdf
SQL Server 2014	오류6.mdf (메시지 2510)	오류6_fixed.mdf
SQL Server 2014	오류2.mdf (메시지 2575)	오류2_fixed.mdf
SQL Server 2014	오류11.mdf (메시지 8905)	오류11_fixed.mdf
SQL Server 2014	오류3.mdf (메시지 5028)	오류3_fixed.mdf
SQL Server 2014	Error8의 .mdf (메시지 5125)	Error8_고정.mdf
SQL Server 2014	오류9.mdf (메시지 3313)	오류9_fixed.mdf

7. 모범 사례

7.1 정기 CHECKDB 작업 예약

중요 운영 데이터베이스에 대해 주간 DBCC CHECKDB 실행을 구현하고, 트랜잭션이 많은 시스템에 대해서는 매일 점검을 수행합니다. 성능 영향을 최소화하기 위해 사용량이 적은 기간에 작업을 예약하고, 데이터베이스 크기 및 유지 관리 기간에 따라 전체 점검과 PHYSICAL_ONLY 옵션을 번갈아 실행하는 것을 고려합니다. 다음을 통한 자동 스케줄링 SQL Server 에이전트는 중앙 모니터링 및 알림 기능을 제공하는 동시에 일관된 실행을 보장합니다.

7.2 성과 영향 관리

DBCC CHECKDB 작업은 상당한 시스템 리소스를 소모하여 동시 사용자 작업에 영향을 미칠 수 있습니다. 검사 중 CPU 사용률, 메모리 사용량 및 디스크 I/O를 모니터링하여 성능 영향 패턴을 파악하십시오. 정기적인 검사에는 NOINDEX 옵션을 사용하고, 전체 유효성 검사는 월별 유지 관리 기간 동안만 실행하도록 하십시오. 무결성 검사 기간 동안의 기대치를 관리하기 위해 쿼리 시간 초과 확장 및 사용자 통신 전략을 구현하십시오.

7.3 유지 관리 기간 계획

DBCC CHECKDB 스케줄링을 백업 작업, 인덱스 재구축, 통계 업데이트 등 다른 유지 관리 작업과 연계하십시오. 성능 저하나 시간 초과 문제를 유발할 수 있는 리소스 소모가 많은 작업은 중복되지 않도록 하십시오. 데이터베이스 크기 증가 예측을 기반으로 유지 관리 기간을 계획하여 데이터 볼륨 증가에 따른 완전한 무결성 검증에 충분한 시간을 확보하십시오.

7.4 자동 모니터링 및 알림

구성 SQL Server DBCC CHECKDB에서 손상을 식별하는 즉시 관리자에게 알리는 에이전트 알림. 무결성 검사 결과를 추출하고 분류하는 로그 분석 솔루션을 구현하여 추세 분석 및 사전 예방적 문제 식별을 지원합니다. 손상 심각도에 따라 대응 기간과 담당자를 정의하는 에스컬레이션 절차를 구축합니다.

8. DBCC CHECKTABLE: 가벼운 대안

8.1 CHECKDB 대신 CHECKTABLE을 사용해야 하는 경우

DBCC CHECKTABLE은 개별 테이블에 대한 집중적인 무결성 검사를 제공하므로 이상적입니다. tar특정 데이터베이스 객체의 문제 해결 및 유지 관리를 지원합니다. 특정 테이블의 성능 문제를 조사하거나, 전체 데이터베이스 검사 사이에 중요한 비즈니스 테이블의 유효성을 검사하거나, 시간 제약으로 인해 데이터베이스 유효성 검사를 완료할 수 없는 경우 CHECKTABLE을 사용하세요. 이 방법은 전체 CHECKDB 작업이 사용 가능한 유지 관리 기간을 초과하는 대규모 데이터베이스에서 특히 유용합니다.

8.2 DBCC CHECKTABLE 구문 및 예

기본 CHECKTABLE 명령 tar특정 테이블을 가져옵니다:

DBCC CHECKTABLE('YourTable')

CHECKDB와 마찬가지로 CHECKTABLE은 성능 최적화를 위한 NOINDEX 옵션과 손상 해결을 위한 복구 매개변수를 포함한 다양한 옵션을 지원합니다. 또한, 정확한 테이블 식별을 위해 스키마 이름을 지정할 수도 있습니다.

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

이 targeted 접근 방식을 사용하면 업무 시간 동안 시스템 성능을 유지하면서 세부적인 무결성 검증이 가능합니다.

8.3 대규모 데이터베이스의 성능 이점

CHECKTABLE 작업은 전체 데이터베이스 검사보다 훨씬 빠르게 완료되므로 중요 테이블의 무결성을 더 자주 검증할 수 있습니다. 이러한 접근 방식을 통해 필수 비즈니스 테이블의 일일 검증을 수행하는 동시에 포괄적인 CHECKDB 작업은 주별 또는 월별 일정으로 예약할 수 있습니다. 리소스 소비가 감소하므로 CHECKTABLE은 사용자에게 미치는 영향을 최소화하면서 운영 환경에서 실행하기에 적합합니다.

9. CHECKDB가 실패할 때

DBCC CHECKDB는 다음을 포함한 다양한 시나리오에서 실패합니다.

• DBCC CHECKDB 실행 비정상적으로 종료됩니다
• DBCC CHECKDB 실행이 성공적으로 완료되었지만 수리 옵션 데이터베이스를 복구하지 못했습니다.

이런 시나리오에서는 데이터베이스의 손상을 복구하는 데 도움이 되는 보다 전문적인 도구가 필요합니다.

9.1 소개 DataNumen SQL Recovery

DataNumen SQL Recovery 더욱 고급 기능을 제공합니다:

• 가장 좋은 회수율 업계에서
• 심각하게 손상된 데이터베이스 파일을 복구합니다.
• 테이블, 인덱스, 뷰, 트리거, 규칙, 기본값을 포함한 모든 데이터베이스 개체를 복구합니다.
• 저장 프로시저, 스칼라 함수, 인라인 테이블 반환 함수 및 다중 문 테이블 반환 함수를 복구합니다.
• 영구적으로 삭제된 기록을 복구합니다.
• 암호화된 객체를 해독합니다. SQL Server 데이터베이스.
• MDF 파일을 일괄적으로 복구합니다.
• 포괄적인 수리 옵션.
• 고급 로깅 ​​및 보고.
• 모두 지원 SQL Server 버전.
• 기술 지원 가용성
• 정기 업데이트 및 개선

9.2 성공률 비교

복구 성공률은 크게 다릅니다.

• DBCC CHECKDB 및 CHECKTABLE: 1.27% 평균 회복율
• DataNumen: 92.6% 회복율

전체 경쟁 비교는 다음과 같습니다.

9.3 심각한 부패로부터의 회복

심각한 경우를 위한 고급 기능:

• 물리적으로 손상된 저장소에서 복구
• 포맷된 드라이브나 손상된 시스템에서 복구
• 디스크 이미지, 백업 파일, 가상 머신 디스크 파일, 템포에서 복구rary 파일 등

9.4 전문가 솔루션을 고려해야 할 때

• 최근 백업이 없습니다
• DBCC CHECKDB가 실패했습니다
• 심각한 부패 시나리오
• 중요한 비즈니스 데이터 처리
• 시간이 중요할 때
• 최대 회복이 필수적인 경우

10. FAQ

11. 결론

11.1 요점 요약

11.1.1 필수 DBCC CHECKDB 명령 요약

포괄적인 데이터베이스 검사를 위한 기본 DBCC CHECKDB 구문을 숙지하고, 성능 최적화를 위해 NOINDEX 및 PHYSICAL_ONLY 옵션을 활용하고, CHECKTABLE을 이해합니다. tar테이블 검증을 수행했습니다. 이러한 기본 명령은 사전 예방적 데이터베이스 유지 관리의 기반을 형성하여 조기 손상 감지 및 체계적인 무결성 모니터링을 가능하게 합니다.

11.1.2 중요 모범 사례 알림

무결성 검사를 실행하기 전에 항상 최신 백업을 유지하고, 데이터베이스 중요도에 따라 정기적인 CHECKDB 작업을 예약하고, 즉각적인 손상 경고를 위한 자동 모니터링을 구현하십시오. 정기적인 모니터링을 통한 예방은 사후 대응 방식보다 중요하며, 표준 도구로는 충분하지 않을 때 전문적인 복구 솔루션이 귀중한 백업 옵션을 제공한다는 점을 명심하십시오.

11.2 DBCC CHECKDB와 고급 솔루션을 사용해야 하는 경우

일상적인 무결성 모니터링 및 사소한 손상 해결에는 DBCC CHECKDB를 사용하고, 내장된 복구 기능을 벗어난 심각한 손상 시나리오에는 전문 복구 도구를 활용하십시오. 의사 결정 프레임워크는 백업 가용성, 데이터 중요도, 시간 제약 및 손상 심각도를 고려해야 합니다. 성공적인 데이터베이스 관리자는 정기적인 CHECKDB 모니터링과 포괄적인 백업 전략을 병행하고, 표준 접근 방식으로는 충분하지 않을 경우 고급 복구 옵션에 대한 이해를 강화해야 합니다.

12. 참조

1. Microsoft Learn. "DBCC CHECKDB(Transact-SQL)." SQL Server 문서. 마이크로소프트 주식회사.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. "DBCC CHECKDB에서 보고된 데이터베이스 일관성 오류 문제를 해결하세요." SQL Server 문서. 마이크로소프트 주식회사.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors