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

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

이 글에서 다루는 내용

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

ORA-16063 switchover is not possible at this time, try later 는?

ORA-16063은 Oracle Data Guard 환경에서 Primary 데이터베이스를 Standby로, 또는 Standby를 Primary로 전환하는 Switchover 작업 중 현재 상태가 전환을 허용하지 않을 때 발생하는 에러입니다. 이 에러는 데이터베이스 간의 Redo 로그 동기화가 완료되지 않았거나, Standby 데이터베이스가 준비되지 않은 상태에서 Switchover 명령을 수행할 때 주로 나타납니다. 실제 운영 환경에서 계획된 유지보수나 마이그레이션 작업 시 이 에러를 마주치면, 작업 일정에 큰 차질이 생길 수 있으므로 원인 파악과 신속한 조치가 필요합니다.


주요 발생 원인

1. Redo 로그 전송 및 적용 지연 (Redo Transport / Apply Lag)

Primary에서 생성된 Redo 데이터가 Standby에 모두 전송되지 않았거나, 전송은 되었지만 아직 Standby에서 적용(Apply)이 완료되지 않은 상태에서 Switchover를 시도할 때 이 에러가 발생합니다. 네트워크 지연, I/O 병목, 또는 Redo Apply 프로세스(MRP)가 일시 중단된 경우 Lag이 증가하여 Switchover 조건을 충족하지 못하게 됩니다.

2. Standby 데이터베이스의 비정상 상태 (Standby Not in Proper State)

Standby 데이터베이스가 MOUNTED 또는 OPEN READ ONLY 상태가 아니거나, MRP(Managed Recovery Process) 혹은 RFS(Remote File Server) 프로세스가 정상적으로 동작하지 않을 때 Switchover가 불가능합니다. 특히 Standby가 비정상 종료 후 재시작되지 않았거나, 아카이브 로그 갭(Archive Log Gap)이 발생한 경우에도 이 상태가 유지됩니다.

3. Data Guard Broker 설정 불일치 또는 비활성화 상태

Data Guard Broker를 사용하는 환경에서 Broker 구성 파일이 손상되었거나, Primary와 Standby 간의 Broker 연결이 끊어진 경우 Switchover 명령이 차단됩니다. DGMGRL을 통한 Switchover 시도 시 내부적으로 상태 검증을 수행하는데, 이 검증 단계에서 불일치가 감지되면 ORA-16063이 반환됩니다.


해결 방법

1단계: 현재 Data Guard 상태 확인

Switchover를 시도하기 전에 반드시 현재 상태를 점검해야 합니다.

-- Primary 데이터베이스에서 실행
SELECT SWITCHOVER_STATUS, DATABASE_ROLE, OPEN_MODE 
FROM V$DATABASE;

-- 결과값 의미:
-- SWITCHOVER_STATUS = 'TO STANDBY'       => Switchover 가능
-- SWITCHOVER_STATUS = 'SESSIONS ACTIVE'  => 활성 세션 존재, 주의 필요
-- SWITCHOVER_STATUS = 'NOT ALLOWED'      => 전환 불가 상태
-- Redo 전송 및 Apply Lag 확인 (Primary에서 실행)
SELECT DEST_ID, STATUS, TARGET, ARCHIVER, SCHEDULE,
       DESTINATION, ERROR, GAP_STATUS
FROM V$ARCHIVE_DEST_STATUS
WHERE TARGET = 'STANDBY';

-- Apply Lag 상세 확인
SELECT NAME, VALUE, DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag', 'apply lag', 'apply finish time');

2단계: Redo Apply Lag 해소

-- Standby 데이터베이스에서 MRP 프로세스 상태 확인
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#
FROM V$MANAGED_STANDBY
ORDER BY PROCESS;

-- MRP가 중단된 경우 재시작 (Standby에서 실행)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Real-time Apply 활성화 (권장)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
    USING CURRENT LOGFILE DISCONNECT;

3단계: 활성 세션 처리 후 Switchover 재시도

SWITCHOVER_STATUS가 ‘SESSIONS ACTIVE’인 경우 아래 명령어를 사용합니다.

-- Primary에서 세션 종료 옵션을 포함한 Switchover (권장)
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 
    WITH SESSION SHUTDOWN;

-- 또는 잠시 대기 후 재시도
-- SWITCHOVER_STATUS가 'TO STANDBY'로 변경될 때까지 모니터링
SELECT SWITCHOVER_STATUS FROM V$DATABASE;

4단계: Data Guard Broker를 통한 상태 점검 및 Switchover

-- DGMGRL 접속 후 상태 확인
-- (SQL*Plus가 아닌 OS 명령어로 실행)
-- dgmgrl sys/password@primary_tns

-- DGMGRL 내부 명령어 (참고용 SQL 블록)
/*
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE VERBOSE 'primary_db';
DGMGRL> SHOW DATABASE VERBOSE 'standby_db';
DGMGRL> VALIDATE DATABASE 'standby_db';
DGMGRL> SWITCHOVER TO 'standby_db';
*/
-- Broker 없이 SQL*Plus로 Switchover 진행 시 전체 절차
-- [Step 1] Primary에서 Standby로 전환 시작
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

-- [Step 2] Primary 인스턴스 재시작 (Standby 역할로)
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

-- [Step 3] 구 Standby(신 Primary)에서 Primary 역할 전환
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

-- [Step 4] 신 Primary에서 Redo 전송 재개
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE;

5단계: Archive Log Gap 해소

-- Standby에서 Archive Gap 확인
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

-- Gap이 존재하는 경우 Primary에서 수동으로 아카이브 로그 등록
-- (Primary에서 실행)
ALTER SYSTEM ARCHIVE LOG CURRENT;

-- Standby에서 수동 로그 등록
ALTER DATABASE REGISTER LOGFILE '/path/to/archivelog/archive.dbf';

예방 방법

1. Data Guard 상태 모니터링 자동화 및 임계값 알림 설정

Switchover 실패의 가장 큰 원인은 Apply Lag 누적과 상태 이상을 사전에 감지하지 못하는 것입니다. V$DATAGUARD_STATS와 V$MANAGED_STANDBY 뷰를 주기적으로 쿼리하는 모니터링 스크립트를 Cron Job 또는 Oracle Enterprise Manager(OEM) 알림으로 구성하여, Apply Lag이 특정 임계값(예: 5분)을 초과하면 즉시 담당자에게 알림이 가도록 설정합니다. 또한 실제 Switchover 전에는 항상 DGMGRL VALIDATE DATABASE 명령이나 V$DATABASE.SWITCHOVER_STATUS 컬럼을 통해 전환 가능 여부를 반드시 사전 확인하는 절차를 표준 운영 절차(SOP)에 포함시켜야 합니다.

2. 정기적인 Switchover 연습(DR Drill) 수행

운영 환경에서 갑작스러운 장애 발생 시 Switchover를 신속하게 수행하려면, 평소에 정기적인 DR(Disaster Recovery) 훈련을 통해 절차를 숙지해 두는 것이 필수적입니다. 최소 분기 1회 이상 계획된 Switchover 및 Switchback을 수행하여 실제 전환 시간을 측정하고, 발생 가능한 문제점을 미리 발견하고 해결책을 문서화해 두어야 합니다. 이를 통해 Broker 구성, 네트워크 경로, 서비스 재등록 등의 잠재적 문제를 사전에 식별할 수 있습니다.


관련 에러

| 에러 코드 | 설명 |

|———–|——|

| ORA-16009 | Remote archive log destination must be a STANDBY database – Standby 대상 설정 오류 |

| ORA-16014 | Log string sequence# string not archived, no available destinations – 아카이브 대상 없음 |

| ORA-16055 | FAL request rejected – FAL(Fetch Archive Log) 요청 거절, Gap 해소 실패 시 |

| ORA-16086 | standby database does not contain available standby log files – Standby Redo Log 부족 |

| ORA-16139 | media recovery required – Standby에서 미디어 복구 필요 시 |

| ORA-16400 | switchover target has not received all redo – Redo 미수신으로 인한 전환 불가 |


DBMS 에러 코드 시리즈

주요 DBMS error code를 정리하는 시리즈입니다.
블로그 홈에서 다른 에러도 확인하세요.

본 포스트는 AI가 생성한 기술 가이드입니다. 운영 환경 적용 전 충분한 검토를 권장합니다.

댓글 남기기