ORA-01210 데이터파일 헤더 미디어 손상으로 RECOVER 실패 시 복구 절차

ORA-01210 데이터파일 헤더 미디어 손상으로 RECOVER 실패 시 복구 절차

아래 내용은 RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL 수행 중
ORA-01210(data file header is media corrupt)로 복구 세션이 중단되는 케이스를 기준으로 정리했습니다.

개요

다음과 같은 로그 흐름은 “아카이브/리두 부족”이 아니라, 특정 데이터파일의 헤더 자체가 물리적으로 손상되어 검증 단계에서 복구가 끊기는 패턴입니다.

SQL> recover database using backup controlfile until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01122: database file <DATAFILE_NO> failed verification check
ORA-01110: data file <DATAFILE_NO>: '+DATA_DG/<DB_UNIQUE>/DATAFILE/undotbs_<N>.<inc>.<stamp>'
ORA-01210: data file header is media corrupt

핵심 포인트 ORA-01210은 “해당 데이터파일을 읽어야 하는데 헤더가 깨져 검증 실패”를 의미합니다.
이 케이스는 보통 해당 데이터파일을 백업에서 RESTORE 후 RECOVER하는 것이 정석입니다.

실무 기준으로 보면, 이 오류는 “UNDO라서 버려도 되지 않나?”라고 접근하면 더 크게 꼬일 수 있습니다.
특히 데이터베이스가 MOUNT 상태에서 복구 중이라면, “새 UNDO 생성/전환”은 OPEN이 필요해 우회가 쉽지 않습니다.

환경

• Oracle DB + ASM 환경 가정 (경로가 +DATA_DG/... 형태)
• 복구 모드: MOUNT 상태에서 USING BACKUP CONTROLFILE 수행
• 문제 파일: UNDOTBS_<N>에 속한 데이터파일(식별정보는 대체 표기)

중요 아래 예시는 데이터파일 번호/파일명/UNDO 번호를 모두 식별불가 형태로 치환했습니다.
실제 적용 시에는 조회 결과로 나온 값만 치환 없이 그대로 사용하세요.

증상

대표 증상

• RECOVER DATABASE ... 실행 즉시 ORA-01122 + ORA-01210으로 중단
• ORA-01110에 특정 데이터파일(ASM 경로)이 반복 표기
• 아카이브 로그를 넣기 전에 검증 단계에서 끊김

의미 해석

오류	현장에서의 의미
ORA-01210	데이터파일 헤더(파일 시작부) 자체가 미디어 손상으로 읽기/검증 불가
ORA-01122	Oracle이 내부 검증을 시도했으나 해당 데이터파일이 검증 실패
ORA-01110	문제의 “대상 데이터파일”을 명시(복구 대상 pinpoint)
ORA-00283	위 오류들 때문에 복구 세션이 취소됨(결과 메시지)

1차 점검

1) 대상 데이터파일 번호/테이블스페이스 재확인

MOUNT에서도 조회 가능한 뷰로 “어느 TS/어느 파일”인지 먼저 고정합니다.

-- SQL*Plus
SELECT file#, name, status, error
  FROM v$datafile
 ORDER BY file#;

SELECT file#, status, error, change#, time
  FROM v$recover_file
 ORDER BY file#;

2) 해당 파일이 실제로 읽히는지(OS/ASM 레벨)

ASM이라면 ASMCMD로 파일 존재/메타를 먼저 확인합니다.

-- OS: grid/oracle 사용자로
asmcmd ls +DATA_DG/<DB_UNIQUE>/DATAFILE/
asmcmd ls +DATA_DG/<DB_UNIQUE>/DATAFILE/undotbs_<N>.*

3) “파일 손상”인지 “경로/권한/디스크”인지 분리

헤더 미디어 손상은 보통 물리 손상 쪽이지만, 스토리지 이슈가 동반될 수 있어 기본 점검은 권장됩니다.

• 스토리지/ASM 디스크그룹 상태(v$asm_diskgroup, asmcmd lsdg)
• OS 로그(디스크 I/O 에러 흔적)
• 동일 DG에서 다른 파일도 읽기 오류가 있는지

심화 분석

분기 A: 백업이 있고, RMAN 사용 가능

가장 표준적인 복구 흐름입니다.
“문제 데이터파일만” 백업본으로 되돌린 뒤, 그 파일만 redo 적용(RECOVER)합니다.

분기 B: 백업이 없거나, 카탈로그/제어파일 정보가 불완전

이 경우는 현실적으로 선택지가 급격히 줄어듭니다.
USING BACKUP CONTROLFILE로 복구를 진행 중이라면 “어차피 백업 기반 복구”를 전제로 하는 경우가 많아서, 백업 소스가 없다면 동일 시점 복구 자체가 불가능할 수 있습니다.

분기 C: 대상이 UNDO 데이터파일일 때의 주의

UNDO라서 그냥 버려도 되지 않나? OPEN 상태라면 “새 UNDO TS 생성 → 전환 → 기존 UNDO drop” 같은 정리가 가능하지만,
지금처럼 MOUNT에서 media recovery를 하는 국면에서는 “새 UNDO 생성/전환”이 막혀있는 경우가 많습니다.
따라서 결론은 대부분 동일합니다: 해당 UNDO 데이터파일도 백업에서 RESTORE 후 RECOVER가 정석입니다.

복구

0) 전제: 상태를 MOUNT로 고정

-- SQL*Plus
SHUTDOWN ABORT;
STARTUP MOUNT;

1) RMAN에서 문제 데이터파일만 RESTORE + RECOVER

아래는 “문제 데이터파일 번호”를 기준으로 진행하는 가장 단순한 절차입니다.

-- RMAN
rman target /

-- (선택) 복구 대상/백업 인식 확인
REPORT SCHEMA;
LIST BACKUP OF DATAFILE <DATAFILE_NO>;

-- 핵심: 손상 파일만 복구
RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  RESTORE DATAFILE <DATAFILE_NO>;
  RECOVER DATAFILE <DATAFILE_NO>;
  RELEASE CHANNEL c1;
}

체크 RESTORE가 성공해도 RECOVER 과정에서 아카이브 로그 요구가 뜰 수 있습니다.
그 경우는 “파일 손상”이 아니라 “적용할 로그가 더 필요”하다는 정상 흐름입니다.

2) 전체 데이터베이스 복구 재시도

문제 파일이 정상화되면, 다시 전체 RECOVER 흐름으로 돌아갑니다.

-- SQL*Plus
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

요구하는 아카이브 로그를 제공할 수 있는 만큼 적용하고, 더 이상 없으면 CANCEL합니다.

3) OPEN RESETLOGS

복구 종료 지점이 “백업 컨트롤파일 기반”이면 보통 RESETLOGS 오픈이 필요합니다.

ALTER DATABASE OPEN RESETLOGS;

4) (가능하면) 손상 검증/재점검

복구 직후 최소한의 검증을 권장합니다.

-- RMAN: 논리/물리 점검(환경에 맞게 선택)
BACKUP VALIDATE CHECK LOGICAL DATABASE;

-- 또는 특정 파일만 점검
VALIDATE DATAFILE <DATAFILE_NO>;

복구 중 막히는 흔한 원인 아카이브 로그 미보유
백업본이 손상/불완전
ASM 디스크그룹/스토리지 레벨 I/O 문제 지속
컨트롤파일/카탈로그 불일치

5) “RMAN 자체가 어려운 환경”일 때 (최소 가이드)

운영 환경에서는 RMAN이 사실상 정답이지만, 복구 툴/백업 소스가 없는 경우는 결론이 빠르게 나옵니다.
아래는 판단 기준만 간단히 정리합니다.

• 해당 데이터파일의 “정상 백업본”이 없으면: 동일 시점 복구는 거의 불가능
• 스토리지 I/O 에러가 계속되면: 복구 반복보다 먼저 스토리지 안정화가 우선
• UNDO 파일이라고 해서 MOUNT에서 임의 재생성은 대부분 막힘: 백업 복구가 정석

재발 방지

1) 백업/아카이브 로그 보존 정책 재점검

• 데이터파일 단위 RESTORE가 가능하도록 RMAN 백업 주기/보관기간 정리
• 아카이브 로그 보관(특히 백업 컨트롤파일 기반 복구 시점 커버)

2) 스토리지/ASM 레벨 사전 감지

• ASM 디스크그룹 상태/리밸런싱/디스크 오류 알람
• OS 커널 로그에서 I/O error, reset, path failover 이벤트 모니터링

3) 장애 시 운영 절차(런북) 고정

실제 사용 시에는 “원인 파악보다 서비스 복구”가 우선인 경우가 많습니다.
그래서 런북에는 최소한 아래 3가지는 고정하는 게 좋습니다.

• 오류 발생 즉시: v$recover_file, v$datafile 출력 확보
• 복구 우선순위: 손상 파일 단위 RESTORE/RECOVER → 전체 RECOVER 재시도
• 복구 이후: VALIDATE + 스토리지 원인 분석(재발 방지)

한 줄 정리 ORA-01210은 “로그를 더 넣으면 된다”가 아니라 “파일 헤더가 깨져 검증 자체가 안 된다”에 가깝습니다.
따라서 대부분의 해법은 문제 데이터파일을 백업에서 복구(RESTORE)하고 다시 RECOVER하는 흐름으로 수렴합니다.