Oracle ORA-16004 오류 원인과 해결 방법 완벽 가이드

ORA-16004
2026년 09월 26일 | DBMS Error 가이드

이 글에서 다루는 내용

ORA-16004 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

ORA-16004 backup database requires recovery 는?

ORA-16004 에러는 Oracle Data Guard 또는 Standby Database 환경에서 데이터베이스를 백업하려 할 때, 해당 데이터베이스가 아직 완전한 복구(Recovery)가 완료되지 않은 상태임을 나타내는 에러입니다. 즉, Standby DB나 Primary DB가 미적용된 아카이브 로그(Archive Log) 혹은 Redo Log가 남아 있어 불완전한 상태에서 백업을 시도할 경우 발생합니다. 이 에러는 RMAN(Recovery Manager)을 통한 백업 작업 수행 중 주로 발생하며, DBA가 즉각적으로 조치하지 않으면 백업 정책의 공백이 발생할 수 있어 운영 환경에서 매우 중요하게 다뤄야 할 에러입니다.

주요 발생 원인

1. Standby Database의 미완료 미디어 복구(Incomplete Media Recovery)

Standby Database 환경에서 아카이브 로그가 아직 완전히 적용되지 않은 상태에서 RMAN 백업을 실행하면 ORA-16004가 발생합니다. Data Guard의 MRP(Managed Recovery Process)가 중단되거나 지연된 경우, Standby DB는 Primary DB와의 동기화가 완료되지 않은 상태가 되며, 이 상태에서의 백업 시도는 데이터 정합성 문제로 이어질 수 있기 때문에 Oracle이 의도적으로 차단합니다. 특히 네트워크 단절 이후 재연결 직후 자동화된 백업 스크립트가 실행될 경우 이 원인이 가장 빈번하게 나타납니다.

2. 불완전 복구(Incomplete Recovery) 이후 OPEN RESETLOGS 미수행

Primary Database에서 불완전 복구(Point-in-Time Recovery 또는 UNTIL SCN 방식 등)를 수행한 후 ALTER DATABASE OPEN RESETLOGS 명령을 실행하지 않고 백업을 시도하는 경우 이 에러가 발생합니다. RESETLOGS 명령 없이 데이터베이스를 오픈하지 않으면 Oracle은 해당 DB가 복구 완료 상태가 아니라고 판단합니다. 이는 복구 작업 중 실수로 백업 스크립트가 기동되거나, 운영 절차 미숙으로 인해 발생하는 경우가 많습니다.

3. RMAN 카탈로그 또는 컨트롤 파일의 메타데이터 불일치

RMAN 리포지토리(카탈로그 DB 또는 컨트롤 파일)에 기록된 백업 메타데이터와 실제 데이터베이스 상태 사이에 불일치가 존재할 때 ORA-16004가 발생할 수 있습니다. 예를 들어 컨트롤 파일이 재생성(RESETLOGS)된 이후 RMAN 카탈로그가 동기화되지 않은 경우, Oracle은 데이터베이스가 복구 필요 상태라고 잘못 인식할 수 있습니다. 이 경우에는 RMAN의 RESYNC CATALOG 명령으로 동기화를 먼저 수행해야 합니다.

해결 방법

원인 1 해결: Standby DB 미디어 복구 완료 후 백업

Standby DB의 MRP 프로세스 상태를 먼저 확인하고, 로그 적용이 완료된 이후 백업을 수행합니다.

-- Standby DB에서 MRP 프로세스 상태 확인
SELECT PROCESS, STATUS, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'MRP0';

-- MRP가 중단된 경우 재시작
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

-- 아카이브 갭(Gap) 확인
SELECT * FROM V$ARCHIVE_GAP;

-- Standby DB와 Primary DB의 SCN 비교
SELECT CURRENT_SCN FROM V$DATABASE;  -- Primary에서 실행
SELECT CURRENT_SCN FROM V$DATABASE;  -- Standby에서 실행 (값 비교)

-- MRP 정상 작동 후 RMAN 백업 실행
RMAN TARGET /
BACKUP DATABASE PLUS ARCHIVELOG;

원인 2 해결: RESETLOGS 수행 후 백업

불완전 복구 이후 반드시 RESETLOGS로 DB를 오픈한 후 백업을 진행합니다.

-- 데이터베이스 복구 완료 확인
SELECT STATUS, RESETLOGS_CHANGE#, RESETLOGS_TIME
FROM V$DATABASE;

-- RESETLOGS로 데이터베이스 오픈 (불완전 복구 이후 필수)
ALTER DATABASE OPEN RESETLOGS;

-- RESETLOGS 이후 즉시 전체 백업 권장 (RMAN)
-- RMAN 접속 후 실행
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;

-- 백업 완료 여부 확인
SELECT START_TIME, END_TIME, STATUS, INPUT_TYPE
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY START_TIME DESC
FETCH FIRST 5 ROWS ONLY;

원인 3 해결: RMAN 카탈로그 재동기화

-- RMAN 카탈로그 DB에 접속하여 동기화
RMAN TARGET / CATALOG rman_user/password@catalog_db

-- 카탈로그 재동기화
RESYNC CATALOG;

-- 카탈로그와 컨트롤 파일 정보 비교 확인
LIST BACKUP SUMMARY;

-- 만약 컨트롤 파일 자체의 정보가 오염된 경우 컨트롤 파일 재생성
-- (사전에 백업 필수)
ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control_backup.ctl';

-- 현재 DB 복구 필요 여부 확인
SELECT RECOVERY_NEEDED FROM V$DATABASE_BLOCK_CORRUPTION;

-- CROSSCHECK로 백업 정합성 검증
CROSSCHECK BACKUP;
DELETE EXPIRED BACKUP;

예방 방법

1. Standby DB 상태 사전 점검 자동화 및 백업 전 검증 스크립트 도입

RMAN 백업 스크립트 실행 전, 자동으로 MRP 프로세스 상태와 아카이브 갭을 점검하는 Pre-Check 스크립트를 백업 파이프라인에 통합하는 것이 Best Practice입니다. 아래와 같이 백업 전 상태를 자동으로 체크하는 쉘 스크립트를 cron에 연동하면 ORA-16004 예방에 효과적입니다.

-- 백업 전 Standby 상태 체크 쿼리 (정기 모니터링용)
SELECT
    NAME,
    DB_UNIQUE_NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS,
    PROTECTION_MODE
FROM V$DATABASE;

-- 아카이브 적용 지연 시간 체크 (30분 이상이면 경고)
SELECT
    NAME,
    VALUE,
    DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('apply lag', 'transport lag');

2. RMAN 백업 후 VALIDATE 및 카탈로그 동기화 자동화

백업 완료 후 BACKUP VALIDATE 명령으로 백업 무결성을 확인하고, 주기적으로 RESYNC CATALOG를 실행하여 메타데이터 불일치를 사전에 방지합니다. 특히 RESETLOGS 이벤트 발생 후에는 반드시 즉시 카탈로그 동기화와 전체 백업을 수행하는 절차를 운영 매뉴얼에 명문화해야 합니다.

-- 백업 후 무결성 검증
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

-- 정기 카탈로그 동기화 (주 1회 권장)
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;