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

ORA-16065
2026년 09월 28일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-16065 standby database is not synchronized with primary 는?

ORA-16065 에러는 Oracle Data Guard 환경에서 Standby 데이터베이스가 Primary 데이터베이스와 동기화되지 않은 상태일 때 발생하는 에러입니다. 주로 Redo Log 전송 또는 적용 과정에서 문제가 생겼을 때, 혹은 네트워크 단절이나 장시간 Standby가 중단된 이후 재기동할 때 이 에러를 마주치게 됩니다. Data Guard Broker나 Switchover/Failover 작업 중에도 이 에러가 트리거될 수 있으므로, DBA라면 반드시 원인과 해결책을 숙지하고 있어야 합니다.

주요 발생 원인

1. Redo Log 전송 중단 (Redo Transport 장애)

Primary에서 Standby로 Redo Log가 정상적으로 전송되지 않으면 두 데이터베이스 간의 SCN(System Change Number) 격차가 발생합니다. 네트워크 불안정, 방화벽 차단, 또는 Log Archive Destination 설정 오류가 주된 원인이며, 이 상태가 지속되면 ORA-16065가 발생합니다.

2. Redo Log 적용(Apply) 프로세스 중단

Standby 측에서 MRP(Managed Recovery Process) 또는 RFS(Remote File Server) 프로세스가 비정상 종료되거나 멈추면, Redo Log가 도착하더라도 적용되지 않아 동기화 격차가 발생합니다. 특히 Standby DB가 장시간 다운된 후 재기동 시 이 문제가 자주 목격됩니다.

3. Archive Log 공간 부족 또는 파일 누락

Standby DB의 Archive Log 저장 공간이 부족하거나, Primary에서 전송된 일부 Archive Log 파일이 누락되었을 경우 적용 체인이 끊겨 동기화가 불가능해집니다. 이 경우 RMAN을 이용한 Incremental Backup 방식의 복구가 필요합니다.

해결 방법

원인 1 해결: Redo Transport 상태 확인 및 재활성화

먼저 Primary와 Standby 양쪽에서 현재 동기화 상태와 GAP 여부를 확인합니다.

-- Primary에서 Redo Log 전송 상태 확인
SELECT DEST_ID, STATUS, TARGET, ARCHIVER, SCHEDULE, DESTINATION, ERROR
FROM V$ARCHIVE_DEST
WHERE TARGET = 'STANDBY';

-- Primary에서 GAP 확인
SELECT * FROM V$ARCHIVE_GAP;

-- Standby에서 적용 상태 확인
SELECT SEQUENCE#, APPLIED, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 1
ORDER BY SEQUENCE# DESC
FETCH FIRST 20 ROWS ONLY;

Log Archive Destination이 비활성화되어 있다면 아래 명령으로 재활성화합니다.

-- Primary에서 Log Archive Destination 재활성화
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE SCOPE=BOTH;

-- 전송 상태 재확인
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;

원인 2 해결: MRP 프로세스 재시작

Standby DB에서 MRP 프로세스 상태를 확인하고, 중단된 경우 재기동합니다.

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

-- MRP 프로세스 중지 (이미 중지된 경우 생략 가능)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- MRP 프로세스 재시작 (Real-Time Apply 포함)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- 적용 지연 상태 확인
SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag', 'apply lag', 'apply rate');

원인 3 해결: Archive Log GAP 복구 (RMAN Incremental Backup 활용)

Archive Log 누락으로 인한 GAP이 크다면 RMAN Incremental Backup을 이용해 복구합니다.

-- Standby에서 현재 적용된 가장 최근 SCN 확인
SELECT CURRENT_SCN FROM V$DATABASE;

-- Primary에서 해당 SCN 기준 Incremental Backup 생성
-- (Primary DB에서 실행)
RMAN TARGET /
RUN {
  BACKUP INCREMENTAL FROM SCN 1234567
  DATABASE FORMAT '/backup/inc_%U.bkp'
  TAG 'FOR_STANDBY_RESYNC';
}

-- Standby에서 Catalog 등록 후 복구
RMAN TARGET /
CATALOG START WITH '/backup/';
RECOVER DATABASE NOREDO;

-- MRP 재시작
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Data Guard Broker를 사용하는 경우, DGMGRL에서도 상태를 확인할 수 있습니다.

-- DGMGRL에서 상태 확인
-- (터미널에서 실행)
-- dgmgrl sys/password@primary
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE standby_db_name;

-- 동기화 강제 시도
VALIDATE DATABASE standby_db_name;

예방 방법

1. Data Guard 모니터링 자동화 및 Alert 설정

운영 환경에서는 V$DATAGUARD_STATS, V$ARCHIVE_DEST_STATUS 뷰를 주기적으로 쿼리하는 모니터링 스크립트를 Cron 또는 Oracle Enterprise Manager를 통해 자동화해야 합니다. Apply Lag이 특정 임계값(예: 30분 이상)을 초과하면 즉시 알림을 받도록 설정하면 장애로 번지기 전에 선제 대응이 가능합니다.

-- Apply Lag 임계값 모니터링 쿼리 (5분마다 실행 권장)
SELECT NAME, VALUE, TIME_COMPUTED
FROM V$DATAGUARD_STATS
WHERE NAME = 'apply lag'
  AND VALUE > INTERVAL '30' MINUTE;

2. 정기적인 Data Guard 유효성 검증 및 Failover 테스트

매월 또는 분기별로 Switchover 테스트를 수행하여 실제 장애 상황에서 Standby가 정상적으로 역할을 수행할 수 있는지 검증해야 합니다. 또한 VALIDATE DATABASE 명령과 RMAN의 VALIDATE 옵션을 활용해 Standby의 무결성을 주기적으로 점검하면 ORA-16065와 같은 동기화 에러를 사전에 탐지할 수 있습니다.