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

ORA-16055
2026년 09월 27일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-16055 FAL request rejected 는?

ORA-16055 에러는 Oracle Data Guard 환경에서 Standby 데이터베이스가 FAL(Fetch Archive Log) 서버에 아카이브 로그 전송을 요청했지만, 해당 요청이 거부되었을 때 발생하는 에러입니다. FAL은 Data Guard 구성에서 아카이브 로그 갭(GAP)을 자동으로 해소하기 위한 메커니즘으로, Primary 또는 다른 FAL 서버로부터 누락된 로그를 가져오는 역할을 합니다. 이 에러는 주로 Data Guard 구성 오류, 네트워크 문제, 또는 Primary 데이터베이스의 설정 문제로 인해 발생하며, Standby 데이터베이스의 로그 적용이 중단될 수 있어 즉각적인 조치가 필요합니다.

주요 발생 원인

FAL_SERVER 및 FAL_CLIENT 파라미터 설정 오류

FAL_SERVER와 FAL_CLIENT 파라미터가 잘못 설정되어 있거나 누락된 경우 ORA-16055 에러가 가장 빈번하게 발생합니다. Standby 데이터베이스에서 FAL_SERVER는 아카이브 로그를 요청할 대상(보통 Primary DB의 TNS 서비스명)을 지정하고, FAL_CLIENT는 Standby 자신의 서비스명을 지정해야 합니다. 이 두 파라미터가 TNS 설정과 일치하지 않으면 Primary 측에서 요청을 인식하지 못해 요청이 거부됩니다.

TNS 연결 및 네트워크 구성 문제

FAL 요청은 내부적으로 Oracle Net(TNS)을 통해 이루어지기 때문에, tnsnames.ora 파일의 항목이 올바르지 않거나 Primary 및 Standby 간의 네트워크 연결이 원활하지 않으면 요청이 거부됩니다. 특히 Primary 데이터베이스의 listener.ora에 Standby DB가 접근할 수 있는 서비스가 등록되어 있지 않거나, 방화벽 정책으로 인해 특정 포트가 차단된 경우에도 이 에러가 발생합니다. 실제 운영 환경에서는 멀티 사이트 구성이나 클라우드 환경에서의 VPN 단절 등도 원인이 될 수 있습니다.

Primary 데이터베이스의 ARCHIVELOG 모드 또는 LOG_ARCHIVE_DEST 설정 문제

Primary 데이터베이스에서 아카이브 로그가 정상적으로 생성되지 않거나, LOG_ARCHIVE_DEST_n 파라미터에서 Standby로의 전송 설정이 누락 혹은 비활성화된 경우에도 FAL 요청이 거부될 수 있습니다. 또한 Primary DB의 아카이브 위치에 디스크 공간이 부족하거나, 아카이브 로그가 이미 삭제된 경우 요청한 로그 자체를 제공할 수 없어 요청이 실패하게 됩니다.

해결 방법

1. FAL_SERVER 및 FAL_CLIENT 파라미터 확인 및 수정

Standby 데이터베이스에 접속하여 현재 파라미터 값을 확인하고, 올바른 값으로 수정합니다.

-- Standby DB에서 현재 FAL 파라미터 확인
SHOW PARAMETER FAL_SERVER;
SHOW PARAMETER FAL_CLIENT;

-- 파라미터 값 수정 (동적 변경 가능)
ALTER SYSTEM SET FAL_SERVER = 'PRIMARY_DB_SERVICE' SCOPE=BOTH;
ALTER SYSTEM SET FAL_CLIENT = 'STANDBY_DB_SERVICE' SCOPE=BOTH;

-- 변경 후 확인
SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME IN ('fal_server', 'fal_client');

> TIP: FAL_SERVER에 지정하는 서비스명은 반드시 tnsnames.ora에 정의되어 있어야 하며, Primary 데이터베이스로 실제 접속이 가능한 서비스명이어야 합니다.

2. TNS 연결 상태 점검

-- Standby DB에서 Primary DB로의 TNS 연결 테스트 (OS 레벨)
-- tnsping PRIMARY_DB_SERVICE

-- Primary DB에서 Standby로의 연결 확인
-- sqlplus sys/password@STANDBY_DB_SERVICE as sysdba

-- Primary DB에서 Data Guard 상태 확인
SELECT DEST_ID, STATUS, TARGET, ARCHIVER, SCHEDULE,
       DESTINATION, ERROR
FROM V$ARCHIVE_DEST
WHERE TARGET = 'STANDBY';

-- Standby 측에서 GAP 상태 확인
SELECT * FROM V$ARCHIVE_GAP;

3. Data Guard Broker를 통한 GAP 해소 및 상태 점검

-- Data Guard Broker 사용 시 상태 확인 (DGMGRL)
-- DGMGRL> SHOW CONFIGURATION;
-- DGMGRL> SHOW DATABASE VERBOSE 'standby_db';

-- Standby DB에서 MRP 프로세스 재시작
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- GAP 수동 확인 및 FAL 수동 요청
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- 필요시 Standby 아카이브 로그 목록 확인
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED
FROM V$ARCHIVED_LOG
WHERE DEST_ID = 1
ORDER BY SEQUENCE# DESC;

4. Primary 측 아카이브 및 LOG_ARCHIVE_DEST 확인

-- Primary DB에서 아카이브 설정 확인
SELECT DEST_ID, STATUS, TARGET, ARCHIVER,
       DESTINATION, DB_UNIQUE_NAME, ERROR
FROM V$ARCHIVE_DEST
WHERE STATUS != 'INACTIVE';

-- LOG_ARCHIVE_DEST_STATE 확인
SHOW PARAMETER LOG_ARCHIVE_DEST_STATE;

-- Standby로의 전송이 비활성화된 경우 활성화
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE SCOPE=BOTH;

-- Primary에서 아카이브 로그 강제 생성 (테스트용)
ALTER SYSTEM ARCHIVE LOG CURRENT;

-- Primary 측 최근 아카이브 로그 확인
SELECT SEQUENCE#, NAME, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG
WHERE STANDBY_DEST = 'NO'
ORDER BY SEQUENCE# DESC
FETCH FIRST 10 ROWS ONLY;

5. Alert 로그에서 상세 에러 확인

-- Alert 로그 경로 확인
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- V$DATAGUARD_STATUS에서 Data Guard 이벤트 확인
SELECT SEVERITY, ERROR_CODE, MESSAGE, TIMESTAMP
FROM V$DATAGUARD_STATUS
ORDER BY TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

예방 방법

정기적인 Data Guard 상태 모니터링 자동화

Data Guard 환경에서는 GAP 발생 여부와 FAL 상태를 주기적으로 점검하는 모니터링 스크립트를 작성하여 크론잡 또는 Oracle Enterprise Manager(OEM)의 경보 기능과 연동하는 것이 중요합니다. 아래 스크립트를 활용하여 매 시간 GAP 여부를 점검하고, GAP이 감지되면 즉시 알림을 받을 수 있도록 운영 체계를 구축하십시오.

“`sql

— 정기 모니터링 스크립트 예시

SELECT ‘ARCHIVE_GAP_CHECK’ AS CHECK_TYPE,

HIGH_SEQUENCE# – LOW_SEQUENCE# + 1 AS GAP_COUNT,

LOW_SEQUENCE#,

HIGH_SEQUENCE#

FROM V$ARCHIVE_GAP;

— Data Guard 동기화 지연 확인

SELECT NAME, VALUE, DATUM_TIME

FROM V$DATAGUARD_STATS

WHERE NAME IN (‘transport lag’, ‘apply lag’);

“`

FAL 파라미터 및 TNS 설정의 변경 관리 철저화

Data Guard 환경에서 서버명, IP 주소, 서비스명 변경 시 반드시 FAL_SERVER, FAL_CLIENT, LOG_ARCHIVE_DEST_n, tnsnames.ora를 동시에 업데이트하고, 변경 후에는 실제 FAL 동작 테스트를 수행해야 합니다. 특히 Primary DB의 switchover 또는 failover 이후에는 새로운 Primary와 Standby의 역할에 맞게 파라미터를 재설정하는 절차를 표준 운영 절차(SOP)에 명문화해 두는 것이 좋습니다.