Oracle 19c 데이터파일 하나 복구: RESTORE·RECOVER 순서와 온라인 전환 기준

Oracle Database 19c에서 특정 데이터파일 하나가 손상되었거나 사라졌다면, 데이터베이스 전체를 곧바로 복구 대상으로 잡지 않는 편이 안전합니다. 데이터베이스가 열려 있고 손상 범위가 일부 파일에 한정됐다면 해당 파일 또는 그 파일이 속한 테이블스페이스를 오프라인으로 전환한 뒤 RESTORE DATAFILE, RECOVER DATAFILE, 온라인 전환 순서로 처리합니다.

이 순서는 완전 복구를 전제로 합니다. 과거 시점으로 되돌리는 불완전 복구, SYSTEM·SYSAUX·UNDO·활성 롤백 세그먼트가 얽힌 장애, 컨트롤 파일 자체의 문제, 아카이브 로그 누락은 같은 명령을 기계적으로 적용할 상황이 아닙니다. 아래 예제는 테스트 환경에서 절차를 이해하기 위한 것이며, 운영 환경에서는 장애 등급과 백업·아카이브 로그 확보 여부를 먼저 판단해야 합니다.

적용 조건과 영향 범위

RESTORE와 RECOVER가 맡는 일

RESTORE DATAFILE은 백업 또는 이미지 복사본에서 물리 파일을 되가져오는 단계입니다. 여기서 파일은 백업 시점의 상태이므로, 그 뒤에 발생한 커밋까지 반영되어 있지 않습니다. RECOVER DATAFILE은 필요한 archived redo와 사용할 수 있는 증분 백업을 적용해 파일 헤더와 데이터 블록을 현재 일관성 지점까지 전진시키는 단계입니다.

따라서 파일이 없다는 이유만으로 RECOVER부터 실행하면 안 됩니다. 반대로 백업본을 복원했다고 해서 온라인으로 전환해도 안 됩니다. 복원은 과거 물리본을 준비하는 일이고, 복구는 그 물리본에 이후 변경을 적용하는 일입니다. 이 둘이 끝나야 데이터베이스가 해당 파일을 일관된 구성원으로 받아들일 수 있습니다.

작업 전: 파일 번호·오류·의존 업무를 좁힌다

경보에 파일 경로가 보이더라도, 운영 명령은 파일 번호를 기준으로 확인하는 편이 명확합니다. 데이터베이스가 열려 있는 경우 V$RECOVER_FILE은 복구가 필요한 파일과 오류를 보여 주고, V$DATAFILE, V$TABLESPACE 조인은 실제 파일과 테이블스페이스 이름을 연결합니다. 복원된 또는 새로 만든 컨트롤 파일에서는 V$RECOVER_FILE 정보가 정확하지 않을 수 있다는 제한도 기억해야 합니다.

SELECT rf.file#,
       df.name AS datafile_name,
       ts.name AS tablespace_name,
       rf.error,
       rf.online_status,
       rf.change#
FROM   v$recover_file rf
       JOIN v$datafile df ON df.file# = rf.file#
       JOIN v$tablespace ts ON ts.ts# = df.ts#
ORDER BY rf.file#;

백업과 필요한 redo를 먼저 확인

복구 창을 열기 전에 RMAN 저장소에서 해당 파일 백업과 archived redo 확보 가능성을 확인합니다. 이 명령은 데이터를 바꾸지 않지만, 목록에 보인다는 사실만으로 복구 완료를 보장하지는 않습니다. 백업 피스 접근성, 암호화 키스토어, 테이프 미디어, 로그 보존 정책도 실제 복구 시간에 영향을 줍니다.

LIST BACKUP OF DATAFILE 7;
LIST ARCHIVELOG ALL;
RESTORE DATAFILE 7 PREVIEW;

최소 재현 예제로 보는 안전한 순서

예제에서는 파일 번호 7이 업무 테이블스페이스 APPDATA에 속한다고 가정합니다. 실제 환경에서는 숫자와 이름을 위 진단 결과로 바꿉니다. SYSTEM, SYSAUX, UNDO의 파일처럼 데이터베이스 기동과 직결되는 구성 요소는 이 단순 예제를 적용하지 말고 장애 런북과 Oracle 복구 문서를 우선합니다.

-- RMAN에 TARGET으로 연결한 뒤 실행
ALTER DATABASE DATAFILE 7 OFFLINE;

RESTORE DATAFILE 7;
RECOVER DATAFILE 7;

ALTER DATABASE DATAFILE 7 ONLINE;

원래 위치에 복원할 수 없을 때

스토리지 장애로 원래 경로를 사용할 수 없으면 새 경로에 복원한 뒤 컨트롤 파일이 새 파일을 가리키도록 전환해야 합니다. 단순히 운영체제에서 파일을 옮기는 방식은 RMAN 저장소와 컨트롤 파일의 인식을 어긋나게 만들 수 있습니다. SET NEWNAME과 SWITCH DATAFILE ALL은 바로 그 연결을 명시적으로 갱신하는 수단입니다.

RUN {
  SET NEWNAME FOR DATAFILE 7 TO '/u02/oradata/ORCL/appdata07.dbf';
  RESTORE DATAFILE 7;
  SWITCH DATAFILE ALL;
  RECOVER DATAFILE 7;
}

ALTER DATABASE DATAFILE 7 ONLINE;

온라인 전환 전후에 확인할 것

SELECT df.file#,
       df.name,
       df.status,
       ts.name AS tablespace_name,
       ts.status AS tablespace_status
FROM   v$datafile df
       JOIN v$tablespace ts ON ts.ts# = df.ts#
WHERE  df.file# = 7;

파일 전체 복구가 아닌 경우

오류가 특정 블록 손상으로 확인되고 데이터파일 전체가 손실되지 않았다면, 파일을 복원하는 대신 RMAN 블록 미디어 복구를 검토합니다. Oracle은 V$DATABASE_BLOCK_CORRUPTION과 진단 로그에서 손상 블록 정보를 확인한 뒤 RECOVER DATAFILE ... BLOCK ... 같은 형태로 대상 블록을 복구할 수 있습니다. 이 방식도 원인 분석, 백업 가용성, 영향 확인 없이 실행해서는 안 됩니다.

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

-- 예: 확인된 손상 블록만 대상으로 하는 RMAN 형식
RECOVER DATAFILE 7 BLOCK 1250;

자주 생기는 실수

• RESTORE와 RECOVER를 같은 뜻으로 여기는 일: 백업본을 되살린 뒤 redo 적용이 빠지면 파일은 최신 일관성 지점에 도달하지 못합니다.
• 파일 번호를 확인하지 않고 테이블스페이스 전체를 오프라인으로 두는 일: 영향 범위를 넓히고 불필요한 업무 중단을 만들 수 있습니다.
• RMAN 출력의 경고를 무시하고 ONLINE을 먼저 실행하는 일: 필요한 archived redo, 경로, 권한 문제를 더 복잡하게 만듭니다.
• 불완전 복구와 완전 복구를 섞는 일: 과거 시점 복구는 대상 범위와 OPEN RESETLOGS 같은 별도 결정이 필요합니다.
• 어제의 RESTORE VALIDATE 결과를 실제 복구 성공으로 해석하는 일: VALIDATE는 복구 계획과 백업 읽기를 확인하지만, 실제 파일 복원·redo 적용·업무 검증을 대신하지 않습니다.

복구 명령보다 먼저 복구 범위를 결정한다

특정 데이터파일 장애에서 가장 위험한 선택은 빠른 명령 하나를 찾는 일입니다. 먼저 파일 손상인지, 블록 손상인지, 일부 파일의 완전 복구인지, 과거 시점으로 되돌려야 하는 사고인지를 나눠야 합니다. 일부 파일의 완전 복구라는 판단이 확인되면 오프라인 전환, RESTORE, RECOVER, 상태 검증, ONLINE 순서가 업무 영향과 데이터 일관성을 함께 관리하는 기준선이 됩니다.

공식 출처

• Oracle Database 19c Backup and Recovery User’s Guide — RMAN quick start
• Oracle Database 19c Backup and Recovery User’s Guide — complete recovery
• Oracle Database 19c Backup and Recovery Reference — RESTORE
• Oracle Database 19c Backup and Recovery User’s Guide — recovery-file diagnostics