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

ORA-12521
2026년 09월 11일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-12521 TNS: listener does not currently know of instance requested in connect descriptor 는?

ORA-12521 에러는 Oracle TNS 리스너가 클라이언트 연결 요청 시 지정한 인스턴스(Instance)를 현재 알지 못할 때 발생하는 네트워크 연결 오류입니다. 즉, 클라이언트의 tnsnames.ora 또는 연결 문자열에 명시된 INSTANCE_NAME이 리스너에 등록되어 있지 않거나, 해당 데이터베이스 인스턴스가 정상적으로 기동되지 않은 상태에서 발생합니다. RAC(Real Application Clusters) 환경이나 인스턴스가 비정상 종료된 단일 인스턴스 환경 모두에서 자주 목격되는 에러입니다.

주요 발생 원인

1. 데이터베이스 인스턴스가 기동되지 않았거나 비정상 종료된 경우

가장 흔한 원인으로, 데이터베이스 인스턴스가 완전히 기동(OPEN 상태)되지 않았거나 비정상적으로 종료된 경우 리스너는 해당 인스턴스 정보를 가지고 있지 않습니다. 특히 인스턴스가 MOUNT 또는 NOMOUNT 상태에 머물러 있는 경우에도 리스너에 등록되지 않아 이 에러가 발생할 수 있습니다.

2. 리스너에 인스턴스가 동적/정적으로 등록되지 않은 경우

Oracle 리스너는 인스턴스 기동 시 PMON 프로세스를 통해 동적으로 등록되는데, 이 동적 등록이 실패하거나 listener.ora에 정적 등록(SID_LIST)이 누락된 경우 클라이언트 연결 요청을 처리하지 못합니다. 특히 RAC 환경에서 특정 노드의 인스턴스가 리스너와 동기화되지 않았을 때 빈번하게 발생합니다.

3. 연결 문자열의 INSTANCE_NAME 또는 SERVICE_NAME 오타 및 불일치

클라이언트 측 tnsnames.ora에 설정된 INSTANCE_NAME 또는 SERVICE_NAME이 실제 데이터베이스에 등록된 이름과 다른 경우에도 이 에러가 발생합니다. 대소문자 구분이나 오타 한 글자로도 리스너는 해당 인스턴스를 찾지 못하며, 이 경우 DBA가 놓치기 쉬운 함정이기도 합니다.

해결 방법

해결책 1: 인스턴스 상태 확인 및 기동

먼저 데이터베이스 인스턴스의 현재 상태를 확인하고, 필요 시 정상 기동합니다.

-- 인스턴스 상태 확인
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS
FROM V$INSTANCE;

-- 인스턴스가 MOUNTED 상태인 경우 OPEN으로 전환
ALTER DATABASE OPEN;

-- 인스턴스가 완전히 내려간 경우 SQL*Plus에서 기동
-- (OS 레벨에서 sysdba 권한으로 접속 후 실행)
STARTUP;

인스턴스 상태가 OPEN이 아닌 경우, 위 명령어로 정상 기동 후 다시 연결을 시도합니다.

해결책 2: 리스너 상태 확인 및 서비스 등록 강제 실행

리스너에 인스턴스가 제대로 등록되어 있는지 확인하고, 등록되지 않은 경우 강제로 재등록합니다.

-- 리스너에 등록된 서비스 목록 확인 (OS 레벨 명령어)
-- lsnrctl status
-- lsnrctl services

-- DB 내에서 현재 등록된 서비스 확인
SELECT NAME, NETWORK_NAME, CREATION_DATE
FROM DBA_SERVICES
ORDER BY NAME;

-- PMON을 통한 동적 등록 강제 실행 (DB 내부에서)
ALTER SYSTEM REGISTER;

-- 서비스가 없는 경우 수동으로 서비스 생성
EXEC DBMS_SERVICE.CREATE_SERVICE(
    service_name    => 'MYSERVICE',
    network_name    => 'MYSERVICE'
);

EXEC DBMS_SERVICE.START_SERVICE('MYSERVICE');

ALTER SYSTEM REGISTER; 명령은 PMON이 즉시 리스너에 인스턴스 정보를 재등록하도록 강제합니다. 일반적으로 이 명령 실행 후 수 초 내에 리스너에 서비스가 등록됩니다.

해결책 3: tnsnames.ora 및 인스턴스 이름 검증

클라이언트의 연결 설정과 실제 인스턴스/서비스 이름이 일치하는지 검증합니다.

-- 실제 인스턴스 이름 및 서비스 이름 확인
SELECT INSTANCE_NAME, SERVICE_NAMES
FROM V$INSTANCE;

-- 데이터베이스에 등록된 서비스 전체 확인
SELECT VALUE
FROM V$PARAMETER
WHERE NAME = 'service_names';

-- 현재 활성화된 서비스 확인
SELECT NAME, ENABLED
FROM V$ACTIVE_SERVICES
ORDER BY NAME;

위 쿼리 결과를 클라이언트의 tnsnames.ora 파일 내용과 비교하여 SERVICE_NAME 또는 SID 항목이 정확히 일치하는지 확인합니다.

# tnsnames.ora 예시 (올바른 설정)
MYDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbserver)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MYSERVICE)   -- 반드시 V$INSTANCE의 SERVICE_NAMES와 일치
    )
  )

해결책 4: listener.ora에 정적 등록 추가 (임시 조치)

동적 등록이 불안정한 환경에서는 listener.ora에 정적으로 SID를 등록합니다.

-- listener.ora에 추가할 내용 (OS 파일 편집 후 리스너 재기동)
-- SID_LIST_LISTENER =
--   (SID_LIST =
--     (SID_DESC =
--       (SID_NAME = MYDB)
--       (ORACLE_HOME = /u01/app/oracle/product/19.3.0/dbhome_1)
--     )
--   )

-- 리스너 재기동 후 상태 확인을 위한 쿼리
SELECT NAME, DESCRIPTION
FROM V$LISTENER_NETWORK;

정적 등록 후에는 반드시 lsnrctl stop → lsnrctl start 순서로 리스너를 재기동해야 적용됩니다.

예방 방법

1. 리스너 동적 등록 모니터링 자동화

PMON의 동적 등록 실패를 사전에 감지하기 위해 아래 쿼리를 스케줄러에 등록하고, 서비스가 등록되지 않은 경우 알람을 발생시키는 모니터링을 구축합니다.

-- 서비스 등록 상태 정기 점검 쿼리 (DBMS_SCHEDULER로 자동화 권장)
SELECT S.NAME AS SERVICE_NAME,
       S.ENABLED,
       I.INSTANCE_NAME,
       I.STATUS
FROM   V$ACTIVE_SERVICES S,
       V$INSTANCE I
WHERE  S.INST_ID = I.INSTANCE_NUMBER(+)
ORDER  BY S.NAME;

이 쿼리를 5~10분 주기로 실행하여 결과가 비어 있거나 STATUS가 OPEN이 아닌 경우 DBA에게 즉시 알림이 가도록 자동화하는 것이 Best Practice입니다.

2. listener.ora와 tnsnames.ora 변경 이력 관리 및 정기 검증

네트워크 설정 파일(listener.ora, tnsnames.ora, sqlnet.ora)은 형상 관리 도구(Git 등)로 버전 관리하고, 분기별로 실제 DB 서비스 이름과의 일치 여부를 검증하는 절차를 수립합니다. 특히 DB 마이그레이션, 패치, 클론 작업 후에는 반드시 연결 설정을 재검증하는 체크리스트를 운영 프로세스에 포함시켜야 합니다.