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

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

이 글에서 다루는 내용

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

ORA-12224 TNS: no listener 는?

ORA-12224 에러는 Oracle 클라이언트가 데이터베이스 서버에 접속을 시도할 때 TNS(Transparent Network Substrate) 리스너가 응답하지 않거나 실행되고 있지 않을 때 발생하는 네트워크 연결 오류입니다. 쉽게 말해, 클라이언트가 데이터베이스 문을 두드렸는데 문지기(Listener)가 없는 상황과 동일합니다. 이 에러는 개발 환경, 운영 환경을 막론하고 DBA라면 반드시 한 번 이상 마주치게 되는 매우 흔한 에러로, 원인을 빠르게 파악하고 조치하는 것이 중요합니다.

주요 발생 원인

1. Oracle Listener 프로세스가 중지된 경우

가장 흔한 원인으로, Oracle Listener 데몬 또는 서비스가 서버에서 실행되지 않고 있는 상태입니다. 서버 재부팅 후 자동 시작 설정이 빠져 있거나, 관리자가 실수로 리스너를 중지시킨 경우, 혹은 리소스 부족으로 리스너가 비정상 종료된 경우가 대표적입니다. 운영 중인 시스템에서 갑작스러운 접속 불가 상황이 발생했다면 가장 먼저 이 원인부터 확인해야 합니다.

2. listener.ora 또는 tnsnames.ora 설정 오류

리스너 설정 파일(listener.ora)에 잘못된 포트 번호, 호스트명, SID 또는 서비스명이 기재되어 있거나, 클라이언트의 tnsnames.ora에 잘못된 접속 정보가 기입된 경우 발생합니다. 특히 데이터베이스 마이그레이션, IP 변경, 포트 변경 작업 이후에 이 설정 파일을 업데이트하지 않았을 때 자주 발생합니다. 설정 파일의 오타 하나가 전체 서비스 장애로 이어질 수 있으므로 변경 후 반드시 검증이 필요합니다.

3. 방화벽 또는 네트워크 차단

Oracle 기본 리스너 포트인 1521번 포트가 방화벽 규칙에 의해 차단된 경우 클라이언트는 리스너에 도달할 수 없어 ORA-12224가 발생합니다. 클라우드 환경(AWS, Azure, OCI 등)에서는 보안 그룹 또는 네트워크 ACL 설정을 놓치는 경우가 많으며, 온프레미스 환경에서도 OS 레벨의 iptables 또는 firewalld 설정이 원인이 될 수 있습니다. 리스너는 정상 동작 중이지만 외부에서 접근이 안 되는 경우 이 원인을 우선적으로 의심해야 합니다.

해결 방법

원인 1: Listener 프로세스 재시작

먼저 리스너 상태를 확인하고 재시작합니다.

-- 서버 OS 명령어로 리스너 상태 확인
-- (SQL*Plus가 아닌 OS 터미널에서 실행)
-- $ lsnrctl status

-- 리스너가 중지된 경우 시작
-- $ lsnrctl start

-- 특정 리스너 이름이 있는 경우
-- $ lsnrctl start LISTENER_MYDB

-- 리스너 재시작
-- $ lsnrctl stop
-- $ lsnrctl start

리스너 기동 후 데이터베이스에 서비스가 등록되었는지 확인합니다.

-- 리스너에 등록된 서비스 확인
-- $ lsnrctl services

-- Oracle DB 내부에서 서비스 등록 수동 갱신
-- (DB가 기동된 상태에서 sqlplus로 접속 후 실행)
ALTER SYSTEM REGISTER;

원인 2: tnsnames.ora 및 listener.ora 설정 검증

클라이언트 측 tnsnames.ora 설정을 확인합니다.

-- tnsnames.ora 올바른 예시 (파일 내용)
/*
MYDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.100)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MYDB.example.com)
    )
  )
*/

-- tnsping 명령으로 접속 가능 여부 테스트
-- $ tnsping MYDB

-- 접속 테스트 (SQL*Plus)
-- $ sqlplus scott/tiger@MYDB

listener.ora 서버 설정 파일 예시입니다.

-- listener.ora 올바른 설정 예시 (서버 파일 내용)
/*
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = db-server.example.com)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = MYDB.example.com)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME = MYDB)
    )
  )
*/

-- 설정 파일 위치 확인 (OS 명령어)
-- $ echo $ORACLE_HOME/network/admin/listener.ora
-- $ echo $TNS_ADMIN

원인 3: 방화벽 및 포트 접근성 확인

-- 포트 열려있는지 OS에서 확인 (서버 측)
-- $ netstat -tlnp | grep 1521
-- $ ss -tlnp | grep 1521

-- 클라이언트에서 포트 접근 테스트
-- $ telnet 192.168.1.100 1521
-- $ nc -zv 192.168.1.100 1521

-- Linux 방화벽에서 1521 포트 허용 (firewalld)
-- $ firewall-cmd --permanent --add-port=1521/tcp
-- $ firewall-cmd --reload

-- iptables 사용 시
-- $ iptables -A INPUT -p tcp --dport 1521 -j ACCEPT

-- 현재 데이터베이스 접속 세션 확인 (DBA 권한 필요)
SELECT s.sid, s.serial#, s.username, s.status,
       s.machine, s.program, s.logon_time
FROM   v$session s
WHERE  s.type = 'USER'
ORDER  BY s.logon_time DESC;

리스너 로그 분석

문제 원인을 정확히 파악하기 위해 리스너 로그를 반드시 확인합니다.

-- 리스너 로그 위치 확인
-- $ lsnrctl status | grep "Log File"

-- 로그 파일 실시간 모니터링
-- $ tail -f $ORACLE_BASE/diag/tnslsnr/hostname/listener/trace/listener.log

-- DB에서 네트워크 관련 파라미터 확인
SELECT name, value
FROM   v$parameter
WHERE  name IN (
    'local_listener',
    'remote_listener',
    'service_names',
    'db_name',
    'db_domain'
)
ORDER  BY name;

예방 방법

1. 리스너 자동 시작 및 모니터링 설정

서버 재부팅 시 리스너가 자동으로 기동되도록 OS 레벨에서 서비스를 등록해야 합니다. Linux 환경에서는 systemd 서비스로 등록하거나, Oracle의 dbstart/dbshut 스크립트를 /etc/rc.d/rc.local에 등록하는 방법을 활용합니다. 또한 OEM(Oracle Enterprise Manager), Zabbix, Nagios 등의 모니터링 도구를 통해 1521 포트와 리스너 프로세스의 상태를 5분 이내 주기로 체크하고, 이상 감지 시 즉각 알람이 발송되도록 설정하는 것이 Best Practice입니다.

-- 리스너 헬스 체크용 쿼리 (정기 모니터링 스크립트에 활용)
-- 접속 가능 여부를 주기적으로 확인하는 쉘 스크립트 내에서 사용
SELECT 'LISTENER_CHECK' AS check_type,
       SYSDATE           AS check_time,
       'OK'              AS status
FROM   dual;

2. 설정 파일 변경 관리 및 백업 체계 수립

listener.ora, tnsnames.ora, sqlnet.ora 파일은 형상 관리 시스템(Git 등)으로 버전을 관리하고, 변경 전 반드시 백업을 수행하는 절차를 표준화해야 합니다. 변경 후에는 tnsping, lsnrctl status 명령으로 즉시 검증하고, 이상이 없음을 확인한 뒤 변경 완료 처리하는 프로세스를 팀 내 필수 절차로 정착시켜야 합니다. 특히 IP 변경이나 포트 변경 작업은 반드시 변경 관리 프로세스(Change Management)를 통해 진행하고, 롤백 계획도 사전에 수립해 두는 것이 중요합니다.