ORA-16055 FAL request rejected 오류: Data Guard 갭 복구 실패

ORA-16055 FAL request rejected 오류: Data Guard 갭 복구 실패 원인과 조치

Oracle Data Guard 구성에서 스탠바이가 아카이브 로그를 따라가지 못해 갭(Gap)이 생겼을 때, FAL(Fetch Archive Log) 메커니즘이 프라이머리(또는 다른 소스)로부터 아카이브 로그를 가져오려다 ORA-16055: FAL request rejected가 발생하는 경우가 있습니다. 운영 환경에서는 이 오류가 “자동 갭 복구가 멈춘 상태”를 의미하는 경우가 많으므로, 네트워크·TNS·FAL 파라미터·인증(패스워드 파일)·DB_UNIQUE_NAME 정합성을 빠르게 점검하는 것이 중요합니다.

실무 기준으로 보면, 이 오류는 ‘거절당한 이유’를 찾는 게임입니다 FAL은 “요청 주체(스탠바이)가 어떤 DB로, 어떤 서비스로, 어떤 계정으로, 어떤 로그를 달라”고 요청합니다.
그중 하나라도 불일치하면 상대가 요청을 거절하고 ORA-16055로 귀결되는 경우가 많습니다.
따라서 1차 점검은 “연결·식별·인증·경로” 4가지를 순서대로 확인하는 것이 가장 빠릅니다.

개요

ORA-16055는 스탠바이가 FAL을 통해 아카이브 로그를 요청했지만, 요청 대상(보통 프라이머리)이 해당 요청을 거절(reject)했을 때 나타납니다. 흔한 트리거는 다음과 같습니다.

• FAL_SERVER / FAL_CLIENT 설정 오류, TNS 서비스명 불일치
• DB_UNIQUE_NAME / DG_CONFIG / LOG_ARCHIVE_DEST_n의 서비스·유니크명 불일치
• SYS 패스워드 파일 불일치(원격 인증 실패)
• 리스너/방화벽/포트 이슈로 인한 연결 실패(간헐 포함)
• 아카이브 로그 접근 경로/권한 문제(요청은 갔는데 제공 불가)
• MRP/Managed Recovery 상태 이상 또는 갭 정보 불일치

환경

아래 점검/조치는 Data Guard(Physical Standby) 기준으로 작성했습니다. (Broker 사용 여부와 무관)

• 구성: Primary DB ↔ Physical Standby DB
• 전송: LGWR ASYNC/ARCH 또는 ARCH 전송
• 복구: MRP(Managed Recovery Process)
• 갭 복구: FAL(Fetch Archive Log)

증상

대표적으로 스탠바이 alert log 또는 SQL*Plus 작업 중 다음 형태의 메시지가 함께 보입니다.

ORA-16055: FAL request rejected
ORA-16057: DGID mismatch between destination setting and target database
ORA-12154: TNS:could not resolve the connect identifier specified
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

운영상으로는 다음과 같이 관측됩니다.

• 스탠바이 apply lag 증가, MRP가 WAIT_FOR_LOG 상태로 오래 머묾
• v$archive_gap에 갭이 남아있는데 자동으로 메워지지 않음
• 프라이머리에는 아카이브가 생성되는데 스탠바이가 받지 못하거나, 받더라도 적용이 멈춤

1차 점검

1) 스탠바이 MRP 상태 확인

-- Standby에서 실행
select process, status, client_process, thread#, sequence#
from v$managed_standby
order by process;

2) 갭 존재 여부 확인

-- Standby에서 실행
select * from v$archive_gap;

-- 적용/전송 지표(있다면)
select name, value, unit from v$dataguard_stats
where name in ('apply lag','transport lag','apply finish time');

3) FAL 파라미터 및 핵심 Data Guard 파라미터 확인

-- Standby에서 실행
show parameter fal;
show parameter db_unique_name;
show parameter log_archive_config;
show parameter log_archive_dest_;

4) TNS/리스너 연결 확인(스탠바이 → 프라이머리)

-- Standby OS에서
tnsping <PRIMARY_SERVICE>

-- 가능하면 SQL 접속까지(네트워크+인증 동시 검증)
sqlplus sys/<password>@<PRIMARY_SERVICE> as sysdba

여기서 바로 갈리는 포인트 1차 점검에서 tnsping은 되는데 sysdba 접속이 실패한다면 패스워드 파일/원격 인증 이슈일 가능성이 큽니다.
반대로 tnsping 자체가 실패하면 서비스명, 리스너 등록, 방화벽, SCAN/VIP, 포트 문제부터 해결해야 합니다.

심화 분석

A. DB_UNIQUE_NAME / DG_CONFIG / DEST 설정 불일치

Data Guard는 대상 DB를 식별할 때 DB_UNIQUE_NAME과 DEST 설정의 매칭이 중요합니다. 특히 ORA-16057(DGID mismatch)와 함께 ORA-16055가 동반되는 경우, LOG_ARCHIVE_DEST_n 또는 LOG_ARCHIVE_CONFIG의 DG_CONFIG가 실제와 다를 가능성이 있습니다.

-- Primary/Standby 각각에서 확인(가능하면)
show parameter db_unique_name;
show parameter log_archive_config;
show parameter log_archive_dest_2;   -- 구성에 따라 번호 다름

체크 포인트: DG_CONFIG에 (PRIMARY_UNIQUE,STANDBY_UNIQUE)가 포함되는지, DEST의 SERVICE가 올바른 TNS를 가리키는지, VALID_FOR가 역할에 맞게 설정됐는지 확인합니다.

B. FAL_SERVER / FAL_CLIENT, 서비스명/등록 문제

FAL_SERVER는 “아카이브를 가져올 대상”을, FAL_CLIENT는 “내가 상대에게 나를 식별시키는 이름” 성격으로 쓰입니다. 구성에 따라 FAL_CLIENT가 필요 없거나, 설정하더라도 TNS/서비스명이 정확히 등록돼야 합니다.

-- Standby에서 확인
show parameter fal_server;
show parameter fal_client;

C. 패스워드 파일 불일치(원격 SYS 인증 실패)

스탠바이가 프라이머리에서 아카이브를 가져오려면(특히 원격 인증), 패스워드 파일이 동일하게 유지되어야 하는 경우가 많습니다. SYS 패스워드 변경 후 동기화가 안 되면 FAL 요청이 거절될 수 있습니다.

-- 공통 확인
show parameter remote_login_passwordfile;

D. 아카이브 로그 제공 측(Primary)에서 파일 접근 불가

요청 대상 DB가 해당 시퀀스의 아카이브 로그를 제공할 수 없는 상태(삭제/미생성/경로 불일치)면, FAL 요청이 정상 처리되지 않습니다. 프라이머리의 아카이브 생성/보관 정책과 삭제 정책을 함께 확인하세요.

E. SRL(Standby Redo Log) 부재/구성 문제로 인한 전송·적용 지연

SRL이 없다고 해서 곧바로 ORA-16055가 발생하는 것은 아니지만, LGWR 전송/실시간 적용 구성에서 SRL 미구성은 지연과 재전송을 유발해 갭 상황을 악화시킬 수 있습니다.

복구

1) TNS/리스너 문제 해결 후 재시도

• tnsping 실패: tnsnames.ora 서비스명, HOST/VIP/SCAN, PORT, SERVICE_NAME 점검
• ORA-12514: 리스너에 서비스 등록 누락(정적 등록 또는 동적 등록 상태 확인)

2) FAL 및 DEST 파라미터 정합성 정리

아래는 “개념 예시”입니다. 실제 값은 환경의 서비스명/유니크명을 기준으로 맞춰야 합니다.

-- Standby에서(예시) FAL 대상 지정
alter system set fal_server='PRIMARY_TNS' scope=both;

-- 필요 시(구성에 따라) 클라이언트 식별
-- alter system set fal_client='STANDBY_TNS' scope=both;

3) 패스워드 파일 동기화(의심 시)

• 상황: tnsping OK, 하지만 sqlplus sys@PRIMARY as sysdba가 인증 실패
• 조치: Primary의 password file을 Standby로 동일하게 배포(파일명/경로/권한 포함)

실제 경로/파일명은 OS/버전/구성에 따라 다르므로, 운영 표준(예: $ORACLE_HOME/dbs)과 보안 정책에 맞게 적용하세요.

4) MRP 재기동

-- Standby에서
alter database recover managed standby database cancel;

-- Real-time apply 사용 시
alter database recover managed standby database using current logfile disconnect from session;

-- Real-time apply 미사용 시(구성에 따라)
-- alter database recover managed standby database disconnect from session;

5) 갭이 계속 남는다면: 수동으로 아카이브 로그 공급

프라이머리에서 해당 시퀀스 아카이브 로그가 실제로 존재하는지 확인하고, 네트워크/공유스토리지/파일 전송을 통해 스탠바이에 전달한 뒤 등록/적용합니다.

-- Standby에서(아카이브 파일을 전달받은 뒤)
alter database register logfile '/path/to/archivelog_<thread>_<seq>.arc';

복구 판단 기준 v$archive_gap가 비워지고, v$managed_standby에서 MRP가 정상적으로 로그를 적용하며, apply lag가 안정적으로 감소하면 복구가 완료된 것으로 판단합니다.

재발 방지

• 이름 표준화: DB_UNIQUE_NAME, TNS 서비스명, DG_CONFIG를 문서로 고정하고 변경 시 검증 절차 추가
• 패스워드 파일 운영: SYS 패스워드 변경 시 Primary→Standby 동기화 체크리스트 포함
• 모니터링: apply lag/transport lag, v$archive_gap, MRP 상태를 상시 경보(임계치 기반)
• 로그 보관 정책: 갭이 생겼을 때 필요한 아카이브 로그가 삭제되지 않도록 보관/삭제 정책 점검
• SRL 구성: 실시간 적용/전송을 쓰는 환경은 Standby Redo Log를 표준으로 구성
• 원격 유지보수 통제: 네트워크 변경(방화벽/라우팅/VIP) 시 Data Guard 연결 테스트를 변경관리 항목에 포함

“갑자기 갭이 생겼다”는 사건은 보통 네트워크/리스너/인증 변경, 또는 보관 정책 변경과 함께 발생합니다. 운영 환경에서는 변경관리와 모니터링이 가장 확실한 재발 방지책입니다.

부록: 빠른 점검 SQL 모음

-- Standby: 갭/적용 상태
select * from v$archive_gap;
select process, status, client_process, thread#, sequence# from v$managed_standby order by process;

-- Primary/Standby: 파라미터
show parameter db_unique_name;
show parameter fal;
show parameter log_archive_config;
show parameter log_archive_dest_;

-- Standby: 지표
select name, value, unit from v$dataguard_stats
where name in ('apply lag','transport lag','apply finish time');