오라클 테이블 Block Corrupt로 인한 백업 실패 조치 정리

오라클 테이블 Block Corrupt로 인한 백업 실패 조치 정리

개요

오라클 데이터베이스에서 테이블 Block Corrupt가 발생하면 특정 테이블 조회 오류뿐 아니라 RMAN 백업 실패로 이어질 수 있다. Block Corrupt는 데이터파일 내부의 특정 블록이 논리적 또는 물리적으로 손상된 상태를 의미하며, 백업 과정에서 해당 블록을 읽는 순간 오류가 발생할 수 있다.

핵심은 손상된 블록의 위치를 먼저 확인한 뒤, 해당 블록이 어떤 객체에 속하는지 식별하고, 복구 가능 여부를 판단하는 것이다.
운영 환경에서는 백업 실패만 보고 RMAN 명령을 반복하기보다 데이터파일, 테이블스페이스, 객체, 스토리지 상태를 함께 점검해야 한다.

환경

이 문서는 오라클 데이터베이스에서 RMAN 백업 중 Block Corrupt 관련 오류가 발생하거나, 특정 테이블 조회 시 블록 손상 오류가 발생하는 상황을 기준으로 정리했다.

항목	내용
DBMS	Oracle Database
백업 방식	RMAN 백업
주요 증상	백업 실패, 특정 테이블 조회 실패, 데이터파일 블록 손상 감지
주요 점검 대상	V$DATABASE_BLOCK_CORRUPTION, RMAN validate, alert log, 데이터파일, 스토리지
영향 범위	손상 블록이 포함된 테이블, 인덱스, LOB, 파티션, 데이터파일

증상

Block Corrupt가 발생하면 백업 중 특정 데이터파일을 읽는 단계에서 실패하거나, 애플리케이션에서 특정 데이터 조회 시 오류가 발생할 수 있다. 손상 범위가 작더라도 백업이 해당 블록을 읽는 순간 오류가 발생하므로 전체 백업 작업이 실패한 것처럼 보일 수 있다.

RMAN 백업 실패 예시

RMAN-03009: failure of backup command
ORA-19566: exceeded limit of 0 corrupt blocks for file
ORA-19870: error while restoring backup piece
ORA-19625: error identifying file

테이블 조회 중 오류 예시

ORA-01578: ORACLE data block corrupted
ORA-01110: data file 7: '/oradata/DB01/users01.dbf'

alert log 확인 시 예시

Corrupt block relative dba: 0x01c12345
Bad check value found during backing up datafile
Reread of blocknum=12345, file=/oradata/DB01/users01.dbf

오류 메시지에 데이터파일 번호와 블록 번호가 표시되는 경우가 많다. 이 정보는 어떤 객체가 손상되었는지 찾는 데 사용된다.

1차 점검

먼저 RMAN 또는 데이터베이스 뷰에서 손상 블록 목록을 확인한다. 이미 감지된 손상 블록은 V$DATABASE_BLOCK_CORRUPTION에서 확인할 수 있다.

손상 블록 확인

SELECT file#,
       block#,
       blocks,
       corruption_change#,
       corruption_type
FROM v$database_block_corruption
ORDER BY file#, block#;

데이터파일 경로 확인

SELECT file_id,
       file_name,
       tablespace_name
FROM dba_data_files
WHERE file_id = &file_number;

해당 블록이 포함된 객체 확인

SELECT owner,
       segment_name,
       segment_type,
       tablespace_name
FROM dba_extents
WHERE file_id = &file_number
  AND &block_number BETWEEN block_id AND block_id + blocks - 1;

여기서 객체가 TABLE인지, INDEX인지, LOB인지, PARTITION인지 확인해야 한다.
인덱스 블록 손상이라면 인덱스 재생성으로 해결될 수 있지만, 테이블 데이터 블록 손상이라면 백업 복구나 데이터 재적재가 필요할 수 있다.

RMAN validate 실행

RMAN> VALIDATE DATABASE;

특정 데이터파일만 확인하려면 아래처럼 실행한다.

RMAN> VALIDATE DATAFILE 7;

백업셋까지 검증하려면 아래 명령을 사용할 수 있다.

RMAN> VALIDATE BACKUPSET 123;

심화 분석

Block Corrupt는 크게 물리적 손상과 논리적 손상으로 나눠 볼 수 있다. 물리적 손상은 디스크, 스토리지, 파일 시스템, I/O 경로 문제와 관련될 수 있고, 논리적 손상은 블록 구조나 내부 데이터 정합성 문제로 나타날 수 있다.

1. 손상 유형 확인

구분	설명	주요 대응
물리적 손상	블록 헤더, 체크섬, 읽기 오류, 디스크 I/O 오류 등	RMAN blockrecover, 백업 복구, 스토리지 점검
논리적 손상	블록은 읽히지만 내부 데이터 구조가 비정상인 상태	DBVERIFY, RMAN validate check logical, 객체 재생성 검토
인덱스 손상	인덱스 세그먼트 블록 손상	인덱스 rebuild 또는 drop 후 recreate
LOB 손상	LOB 세그먼트 또는 LOB 인덱스 손상	영향 행 식별, 재적재, 백업 복구 검토

2. RMAN 논리 검사

물리적 블록 손상뿐 아니라 논리적 손상까지 확인하려면 CHECK LOGICAL 옵션을 사용할 수 있다.

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

특정 데이터파일만 검사할 경우에는 아래처럼 실행한다.

RMAN> BACKUP VALIDATE CHECK LOGICAL DATAFILE 7;

3. DBVERIFY로 데이터파일 확인

DB가 내려가 있거나 특정 데이터파일을 별도로 검사해야 하는 경우 dbv 명령을 사용할 수 있다.

dbv file=/oradata/DB01/users01.dbf blocksize=8192

DBVERIFY는 데이터파일 단위로 블록 이상 여부를 확인하는 데 유용하다. 단, 운영 중인 DB 파일에 대해 실행할 때는 I/O 부하가 발생할 수 있으므로 작업 시간대를 고려해야 한다.

4. alert log와 OS 로그 확인

Block Corrupt가 실제 디스크 문제에서 시작된 것인지 확인하려면 DB alert log와 OS 로그를 함께 봐야 한다.

tail -f $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log

dmesg -T | egrep -i "error|fail|scsi|disk|io|timeout"

journalctl -k | egrep -i "error|fail|scsi|disk|io|timeout"

관리자 입장에서 Block Corrupt는 DB 내부 문제처럼 보이더라도 실제 원인은 스토리지, HBA, SAN 경로, 파일 시스템, 백업 솔루션 I/O 충돌에서 시작될 수 있다.

복구

복구 방식은 손상된 블록이 어떤 객체에 속하는지에 따라 달라진다. 인덱스 손상인지, 테이블 데이터 손상인지, LOB 손상인지에 따라 조치 방법이 다르므로 객체 식별이 먼저다.

1. 인덱스 블록 손상인 경우

손상 블록이 인덱스 세그먼트에 속한다면 인덱스 재생성으로 해결되는 경우가 많다.

ALTER INDEX 소유자.인덱스명 REBUILD ONLINE;

온라인 재생성이 불가능한 환경이라면 업무 영향 시간을 잡고 재생성한다.

DROP INDEX 소유자.인덱스명;

CREATE INDEX 소유자.인덱스명
ON 소유자.테이블명(컬럼명);

인덱스를 삭제 후 재생성할 경우 기존 인덱스 옵션, 유니크 여부, 파티션 여부, 병렬도, 테이블스페이스 설정을 반드시 확인해야 한다.
운영 환경에서는 기존 DDL을 먼저 추출한 뒤 작업하는 것이 안전하다.

2. 테이블 데이터 블록 손상인 경우

손상 블록이 테이블 데이터 세그먼트라면 단순 rebuild로 해결되지 않는다. 사용 가능한 정상 백업이 있다면 RMAN 블록 복구를 우선 검토한다.

RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 12345;

여러 블록이 손상된 경우에는 V$DATABASE_BLOCK_CORRUPTION 기준으로 복구할 수 있다.

RMAN> RECOVER CORRUPTION LIST;

블록 복구를 위해서는 해당 블록의 정상 이미지가 포함된 백업과 필요한 아카이브 로그가 있어야 한다. 백업이 없거나 아카이브 로그가 부족하면 테이블 단위 복구, export/import, 데이터 재적재를 검토해야 한다.

3. 백업은 실패하지만 업무 조회는 가능한 경우

업무에서는 아직 해당 블록을 읽지 않아 정상처럼 보일 수 있다. 그러나 백업은 전체 데이터파일을 순차적으로 읽기 때문에 손상 블록을 만나면 실패할 수 있다.

이 경우 임시로 RMAN의 허용 손상 블록 수를 설정해 백업을 진행할 수는 있지만, 이는 근본 해결이 아니다.

RMAN> RUN {
  SET MAXCORRUPT FOR DATAFILE 7 TO 10;
  BACKUP DATAFILE 7;
}

SET MAXCORRUPT는 백업을 통과시키기 위한 임시 조치일 뿐이다.
손상 블록이 포함된 상태로 백업을 계속 유지하면 복구 시점에 데이터 유실이나 복구 실패가 발생할 수 있다.
반드시 손상 객체 식별과 복구 계획을 함께 진행해야 한다.

4. 백업본에서 테이블 단위 복구

특정 테이블만 손상되었고 전체 DB 복구가 어려운 경우, 정상 백업에서 보조 인스턴스 또는 별도 서버로 복구한 뒤 해당 테이블 데이터를 추출하는 방식을 사용할 수 있다.

expdp system/password schemas=소유자 tables=테이블명 directory=DATA_PUMP_DIR dumpfile=table_restore.dmp logfile=table_restore.log

impdp system/password schemas=소유자 tables=테이블명 directory=DATA_PUMP_DIR dumpfile=table_restore.dmp logfile=table_import.log

이 방식은 복구 대상 시점, 데이터 정합성, 업무 중단 가능성, 외래키 관계를 함께 검토해야 한다.

5. 손상 행 우회 후 정상 데이터 이관

일부 블록만 손상되어 있고 백업 복구가 불가능한 경우, 정상적으로 읽히는 데이터를 새 테이블로 이관하는 방법을 검토할 수 있다. 다만 손상 블록에 포함된 행은 읽을 수 없을 수 있으므로 데이터 유실 가능성을 명확히 판단해야 한다.

CREATE TABLE 소유자.테이블명_NEW AS
SELECT *
FROM 소유자.테이블명
WHERE 조건;

대용량 테이블에서는 범위 조건을 나눠 정상 구간을 분리 이관하는 방식이 필요할 수 있다.

재발 방지

Block Corrupt가 한 번 발생했다면 DB 내부 복구만으로 끝내지 말고 스토리지와 OS 계층까지 점검해야 한다. 실제 사용 시 블록 손상은 디스크 장애, 스토리지 컨트롤러 오류, SAN 경로 문제, 파일 시스템 이상, 비정상 종료와 함께 발생하는 경우가 있다.

1. 정기적인 RMAN 검증

RMAN> BACKUP VALIDATE DATABASE;

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

백업 성공 여부만 확인하지 말고 정기적으로 validate를 수행해 실제 복구 가능성과 블록 상태를 확인해야 한다.

2. 블록 체크 관련 파라미터 검토

SHOW PARAMETER db_block_checking
SHOW PARAMETER db_block_checksum

블록 체크와 체크섬 설정은 손상 감지에 도움이 되지만, 환경에 따라 성능 영향이 있을 수 있다. 운영 환경에서는 부하 특성과 장애 예방 수준을 함께 고려해 설정한다.

3. 백업 정책 점검

전체 백업과 아카이브 로그 백업이 정상 수행되는지 확인한다.
RMAN backup validate를 정기 작업에 포함한다.
백업 파일만 보관하지 말고 주기적으로 복구 테스트를 수행한다.
아카이브 로그 보관 기간이 복구 목표 시간과 맞는지 확인한다.
백업 실패 시 재시도보다 손상 블록 목록 확인을 우선한다.

4. 스토리지와 OS 로그 점검

dmesg -T | egrep -i "error|fail|scsi|disk|io|timeout"
journalctl -k | egrep -i "error|fail|scsi|disk|io|timeout"

같은 데이터파일에서 손상 블록이 반복되거나 특정 디스크 경로에서 I/O 오류가 보이면 스토리지 장애 가능성을 우선 점검해야 한다.

5. 장애 대응 절차 표준화

단계	조치	목적
1단계	RMAN 오류와 alert log 수집	손상 데이터파일과 블록 번호 확인
2단계	V$DATABASE_BLOCK_CORRUPTION 조회	현재 DB가 인지한 손상 블록 목록 확인
3단계	DBA_EXTENTS로 객체 식별	테이블, 인덱스, LOB 등 영향 객체 확인
4단계	RMAN blockrecover 또는 객체 재생성	손상 블록 복구 또는 우회
5단계	RMAN validate 재수행	복구 완료 여부 확인
6단계	스토리지와 OS 로그 점검	재발 원인 제거

정리

오라클 테이블 Block Corrupt로 인한 백업 실패는 단순 백업 오류가 아니라 데이터파일 내부의 특정 블록을 정상적으로 읽지 못하는 상태다. 따라서 RMAN 백업 명령을 반복하기보다 손상 블록 번호, 데이터파일, 객체명을 먼저 확인해야 한다.

손상 대상이 인덱스라면 재생성으로 해결될 가능성이 높고, 테이블 데이터 블록이라면 RMAN 블록 복구, 정상 백업 기반 복구, 데이터 재이관을 검토해야 한다. 복구 후에는 반드시 RMAN VALIDATE를 다시 수행해 손상 블록이 제거되었는지 확인하는 것이 중요하다.

최종 판단 기준은 손상 블록이 어느 객체에 속하는지다.
인덱스 손상은 재생성, 테이블 데이터 손상은 RMAN 복구 또는 데이터 복구 절차, 반복 손상은 스토리지 점검으로 이어져야 한다.