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

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

이 글에서 다루는 내용

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

ORA-16058 standby database not available or not mounted 는?

ORA-16058 에러는 Oracle Data Guard 환경에서 Primary 데이터베이스가 Standby 데이터베이스와 통신을 시도할 때, Standby 데이터베이스가 사용 불가능하거나 마운트되지 않은 상태일 때 발생하는 에러입니다. 이 에러는 주로 Redo 로그 전송(Log Shipping) 과정이나 Data Guard Broker가 Standby 인스턴스의 상태를 확인하려 할 때 발생합니다. 실무 환경에서는 Standby 서버의 예기치 않은 재시작, 네트워크 단절, 또는 잘못된 운영 절차 수행 이후에 자주 목격되는 에러입니다.

주요 발생 원인

1. Standby 데이터베이스가 MOUNT 상태가 아닌 경우

Data Guard 구성에서 Standby 데이터베이스는 최소한 MOUNT 상태여야 Redo 로그를 수신하고 적용할 수 있습니다. Standby 인스턴스가 NOMOUNT 상태이거나, 완전히 종료(SHUTDOWN)된 경우 Primary는 연결 자체를 수립할 수 없어 ORA-16058이 발생합니다. 이 경우 DBA가 의도적으로 Standby를 내렸거나, 패치 작업 이후 재기동을 누락한 상황에서 특히 자주 발생합니다.

2. 네트워크 연결 문제 또는 TNS 설정 오류

Primary와 Standby 간의 네트워크 경로가 차단되거나, tnsnames.ora 혹은 listener.ora 설정이 잘못된 경우 Primary가 Standby에 접근 자체를 못하게 됩니다. 방화벽 정책 변경, IP 주소 변경, 또는 리스너 포트 변경 이후 TNS 정보를 업데이트하지 않으면 해당 에러가 발생할 수 있습니다. 이 경우 Alert Log에 ORA-12541(TNS: no listener)이나 ORA-12170(TNS: Connect timeout)과 같은 하위 에러가 함께 출력됩니다.

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

Oracle Data Guard Broker(DGMGRL)를 사용하는 환경에서 Broker 구성 파일이 손상되었거나, DG_BROKER_START 파라미터가 FALSE로 설정된 경우 Broker가 Standby 상태를 정확히 파악하지 못하고 ORA-16058을 반환하는 경우가 있습니다. 또한 Broker가 관리하는 Standby의 상태 정보가 실제 DB 상태와 불일치(Out of Sync)하게 될 때 이 에러가 유발될 수 있습니다.

해결 방법

원인 1: Standby 데이터베이스를 MOUNT 상태로 기동

Standby 서버에 접속하여 인스턴스 상태를 확인하고, MOUNT 상태로 기동합니다.

-- Standby 서버에서 현재 상태 확인
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS
FROM V$INSTANCE;

-- Standby DB가 종료된 경우, MOUNT 상태로 기동
STARTUP MOUNT;

-- 이미 NOMOUNT 상태인 경우
ALTER DATABASE MOUNT;

-- Managed Recovery Process(MRP) 시작
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Standby 상태 확인
SELECT DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE
FROM V$DATABASE;

Standby가 MOUNT 상태로 올라온 뒤 Primary 쪽 Alert Log를 확인하면 Redo 전송이 재개되는 로그를 확인할 수 있습니다.

원인 2: 네트워크 및 TNS 설정 점검

Primary 서버에서 Standby로의 TNS 연결을 직접 테스트합니다.

-- Primary 서버 OS에서 TNS 핑 테스트 (SQL*Plus 외부)
-- tnsping STANDBY_TNS_ALIAS

-- Primary DB에서 Standby로 DB Link 연결 테스트
-- (사전에 DB Link가 설정된 경우)
SELECT * FROM DUAL@STANDBY_LINK;

-- LOG_ARCHIVE_DEST 설정 확인
SELECT DEST_ID, DEST_NAME, STATUS, TARGET, ARCHIVER,
       SCHEDULE, DESTINATION, ERROR
FROM V$ARCHIVE_DEST
WHERE TARGET = 'STANDBY';

-- 에러 상세 정보 확인
SELECT DEST_ID, ERROR, FAIL_DATE, FAIL_SEQUENCE, FAIL_BLOCK
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS != 'VALID';

TNS 설정 파일(tnsnames.ora)에서 Standby의 HOST, PORT, SERVICE_NAME이 정확한지 확인하고, 방화벽에서 해당 포트가 열려 있는지 네트워크 팀과 협력하여 점검합니다.

-- LOG_ARCHIVE_DEST 재설정 예시 (서비스명, 포트 수정 후)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 =
    'SERVICE=STANDBY_DB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
     DB_UNIQUE_NAME=STANDBY_UNIQUE_NAME'
SCOPE=BOTH;

-- 설정 적용 후 아카이브 로그 수동 전송 테스트
ALTER SYSTEM ARCHIVE LOG CURRENT;

원인 3: Data Guard Broker 재구성 및 활성화

-- Primary에서 DG_BROKER_START 파라미터 확인
SHOW PARAMETER DG_BROKER_START;

-- Broker가 비활성화된 경우 활성화
ALTER SYSTEM SET DG_BROKER_START = TRUE SCOPE=BOTH;

-- Standby에서도 동일하게 설정
ALTER SYSTEM SET DG_BROKER_START = TRUE SCOPE=BOTH;

DGMGRL(Data Guard Manager)을 통해 구성 상태를 점검합니다.

-- OS 레벨에서 DGMGRL 접속 (Primary 서버)
-- dgmgrl /

-- DGMGRL 내부 명령어
-- SHOW CONFIGURATION;
-- SHOW DATABASE VERBOSE 'STANDBY_DB_NAME';

-- 만약 Standby 상태가 비정상이면 재활성화
-- ENABLE DATABASE 'STANDBY_DB_NAME';

-- 구성이 심각하게 손상된 경우 Broker 재구성
-- REMOVE CONFIGURATION;
-- CREATE CONFIGURATION 'DG_CONFIG' AS
--   PRIMARY DATABASE IS 'PRIMARY_DB'
--   CONNECT IDENTIFIER IS PRIMARY_TNS;
-- ADD DATABASE 'STANDBY_DB'
--   AS CONNECT IDENTIFIER IS STANDBY_TNS
--   MAINTAINED AS PHYSICAL;
-- ENABLE CONFIGURATION;

Broker 재구성 후 SHOW CONFIGURATION 명령어 실행 시 SUCCESS 상태가 출력되면 정상입니다.

예방 방법

1. Data Guard 상태 모니터링 자동화

Cron Job 또는 Oracle Enterprise Manager(OEM)를 활용하여 주기적으로 Standby 상태를 점검하는 모니터링 스크립트를 구성합니다. 아래 쿼리를 스케줄링하여 이상 감지 시 즉시 알림을 받도록 설정합니다.

-- Standby 상태 및 Transport Lag, Apply Lag 모니터링
SELECT NAME,
       VALUE,
       UNIT,
       TIME_COMPUTED
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag', 'apply lag', 'apply finish time');

-- Archive Dest 에러 여부 주기적 점검
SELECT DEST_ID, STATUS, ERROR, FAIL_DATE
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS != 'VALID'
  AND TARGET = 'STANDBY';

이 쿼리를 5~10분 단위로 실행하고, 에러 발생 시 DBA에게 이메일 또는 SMS 알림이 전송되도록 OEM Alert Rule이나 Shell Script를 구성하면 조기에 문제를 탐지할 수 있습니다.

2. Standby 기동/종료 절차 표준화 (Runbook 작성)

패치 작업, 서버 점검, 계획된 다운타임 발생 시 Standby 데이터베이스의 기동/종료 절차를 반드시 문서화된 Runbook에 따라 수행합니다. 특히 작업 완료 후 Standby를 MOUNT 상태로 복구하고, MRP가 정상 기동되었는지 확인하는 체크리스트 항목을 필수로 포함합니다. Data Guard Broker 환경에서는 작업 전후 SHOW CONFIGURATION 명령어로 상태를 반드시 확인하는 절차를 표준화합니다.