ORA-12541 TNS no listener — TNS 리스너 없음 에러 원인·해결·예방
Oracle 클라이언트가 데이터베이스 서버 호스트에 TCP로 도달했지만 지정된 포트에서 리스너 프로세스가 응답하지 않을 때 ORA-12541: TNS:no listener 에러가 발생한다. ORA-12154가 "어디로 갈지 모르는" 클라이언트 측 이름 해석 실패라면, ORA-12541은 "도착했는데 문을 두드릴 사람이 없는" 서버 측 리스너 부재 신호다.
본 글은 ORA-12541의 정확한 의미와 인접 TNS 에러와의 구분, 7가지 발생 원인, 서버·클라이언트 진단 명령, listener.ora 표준 작성과 동적·정적 등록 메커니즘, RAC SCAN 리스너까지 정리한 트러블슈팅 자료다.
이 글의 구성
01 에러 메시지와 ORA-12541의 의미
| 항목 | 내용 |
|---|---|
| 에러 코드 | ORA-12541 |
| 영문 메시지 | TNS:no listener |
| 12c+ 개선 메시지 | Cannot connect. No listener at host_port. |
| Cause (공식) | The connection request could not be completed because the listener is not running. |
| Action (공식) | 리스너 상태 확인 후 기동, 호스트·포트 정합성 점검 |
| 발생 단계 | 호스트 도달 후 서버 응답 단계 (이름 해석·DNS 이후) |
TNS 연결 단계와 ORA-12541의 위치
- 이름 해석 ━ 클라이언트가 별칭을 호스트:포트:서비스로 매핑 (실패 시 ORA-12154)
- DNS 해석 ━ 호스트명을 IP로 변환 (실패 시 ORA-12545)
- TCP 연결 ━ 호스트의 포트에 도달 (실패 시 ORA-12170)
- 리스너 응답 ━ 그 포트에서 리스너 프로세스 응답 (실패 시 ORA-12541)
- 서비스 등록 ━ 리스너가 SERVICE_NAME 인식 (실패 시 ORA-12514)
핵심 관찰 — 서버 측 리스너 프로세스를 의심하라
ORA-12541은 "클라이언트가 목적지에 도달했지만 그 포트에 응답하는 리스너가 없는" 상태다. 즉 네트워크는 문제없고 서버 호스트는 살아 있다는 전제가 깔린 에러다. 따라서 진단의 첫 단계는 lsnrctl status로 서버 측 리스너 프로세스 자체를 확인하는 것이다.
02 발생 원인 7가지
원인 1 — 리스너 프로세스 미기동
가장 흔한 케이스. DB 서버 OS는 살아 있는데 리스너 프로세스만 죽어 있다. 재부팅 후 자동시작 실패, 운영자 실수로 stop, 리소스 부족으로 인한 crash가 원인이다.
원인 2 — 다른 포트에서 LISTEN
리스너가 1521이 아닌 다른 포트(1525, 1539 등)에서 떠 있고 클라이언트는 1521로 접속을 시도하는 경우다. 비표준 포트로 변경했는데 클라이언트 tnsnames.ora를 업데이트하지 않았을 때 발생한다.
원인 3 — 방화벽·보안 그룹 차단
운영·클라우드 환경에서 가장 빈번한 원인이다. AWS Security Group, Azure NSG, 사내 방화벽 규칙이 1521(TCP)을 막고 있으면 TCP 연결 자체가 실패한다. 방화벽이 패킷을 DROP하면 응답 없음으로 ORA-12170이 발생하고, REJECT(RST 반환) 또는 포트는 열렸지만 리스너가 없는 경우 ORA-12541로 표시된다.
원인 4 — HOST/PORT 오타·DNS 캐시
tnsnames.ora의 HOST가 잘못된 IP·호스트명, PORT가 잘못된 포트인 경우다. DNS가 변경됐는데 클라이언트 캐시에 옛 IP가 남은 경우도 같은 증상이다.
원인 5 — 비정상 종료 후 자동 재시작 미설정
리스너 프로세스가 크래시했는데 systemd·service 단위로 자동 재시작이 설정되지 않은 환경에서 발생한다. listener.log를 확인해 마지막 종료 시각과 원인을 파악한다.
원인 6 — RAC SCAN 리스너 장애
RAC 환경에서 SCAN VIP가 떠 있는 노드의 SCAN 리스너가 죽어 있을 때 발생한다. 다른 SCAN VIP로 자동 페일오버되지만 일시적으로 실패할 수 있다. srvctl status scan_listener로 확인한다.
원인 7 — LOCAL_LISTENER 불일치
비표준 포트를 사용하는 환경에서 인스턴스의 LOCAL_LISTENER 파라미터가 실제 리스너와 다른 주소를 가리키는 경우다. 인스턴스가 잘못된 리스너에 등록을 시도하므로 진짜 리스너에는 서비스가 등록되지 않은 상태가 된다(ORA-12541 또는 ORA-12514).
03 재현 시나리오와 진단 명령
재현 — 리스너 정지 후 연결 시도
# 서버: 리스너 정지
lsnrctl stop LISTENER
# 클라이언트: 연결 시도
sqlplus scott/tiger@//dbhost:1521/ORCLPDB1
# ✗ ORA-12541: TNS:no listener
# 서버: 다시 기동
lsnrctl start LISTENER
# ✓ Listening Endpoints Summary 표시
서버 측 진단 명령
# 기본 리스너 상태
lsnrctl status
# 특정 리스너 (RAC SCAN 등)
lsnrctl status LISTENER_SCAN1
# 등록된 서비스·인스턴스
lsnrctl services
# 프로세스 확인
ps -ef | grep tnslsnr | grep -v grep
# 포트 LISTEN 상태 (Linux)
ss -tlnp | grep 1521
netstat -tlnp | grep 1521
# 리스너 로그 (이상 종료·등록 이력)
tail -100 $ORACLE_BASE/diag/tnslsnr/<host>/listener/trace/listener.log
클라이언트 측 진단 명령
# 별칭 해석 + TNS 레이어 확인
tnsping ORCLPDB
# TCP 도달성
telnet dbhost 1521
nc -zv dbhost 1521
# DNS 검증
nslookup dbhost
getent hosts dbhost
# 라우팅 확인
traceroute dbhost
판단 흐름은 다음과 같다.
nc성공 +tnsping실패 → 포트는 열려 있지만 리스너가 응답 이상nc실패 +nslookup성공 → 호스트는 알지만 포트 차단 (방화벽)nc실패 +nslookup실패 → DNS 해석 단계부터 문제 (ORA-12545가 더 적절)tnsping성공 +sqlplus실패 → 리스너는 살아 있고 다른 단계 문제
04 해결 방법과 디버깅 순서
해결 방법 5가지
| 방법 | 설명 |
|---|---|
| 리스너 기동 | lsnrctl start로 즉시 복구, RAC는 srvctl start scan_listener |
| 포트·HOST 정합 | 서버 listener.ora와 클라이언트 tnsnames.ora의 HOST·PORT 일치 점검 |
| 방화벽 허용 | 보안 그룹·iptables·firewalld에 DB 포트 인바운드 규칙 추가 |
| 자동 재시작 | systemd Restart=on-failure로 리스너 죽으면 자동 기동 |
| LOCAL_LISTENER | 비표준 포트 사용 시 ALTER SYSTEM SET LOCAL_LISTENER 명시 |
디버깅 순서
단계별 진단 절차
05 listener.ora와 등록 메커니즘
listener.ora 예시 (동적 + 정적 혼합)
# 기본 LISTENER 정의 (동적 등록만 쓰면 보통 이게 전부)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbhost.corp.local)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
# 정적 등록 (DB 미기동 상태에서도 원격 startup 필요한 경우)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ORCL)
(ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
(SID_NAME = ORCL)
)
)
동적 등록 vs 정적 등록
| 구분 | 동적 등록 (Dynamic) | 정적 등록 (Static) |
|---|---|---|
| 등록 주체 | 인스턴스 LREG (12c+, 11g 이하 PMON) | DBA가 수동 기재 |
| 위치 | listener.ora에 기재 없음 | SID_LIST_LISTENER |
| 우선순위 | 동적이 우선 | 동적이 없을 때 사용 |
| 필요 시점 | 일반 운영 (기본) | DB 미기동 상태 원격 startup, RMAN duplicate, Data Guard 초기 구성 |
LOCAL_LISTENER / REMOTE_LISTENER 설정
-- 비표준 포트(1525) 사용 시 LOCAL_LISTENER 명시
ALTER SYSTEM SET LOCAL_LISTENER =
'(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost)(PORT=1525))'
SCOPE=BOTH;
-- RAC: 모든 노드의 SCAN 리스너로 서비스 등록 (부하 분산·페일오버)
ALTER SYSTEM SET REMOTE_LISTENER =
'scan-name.corp.local:1521';
-- 즉시 재등록
ALTER SYSTEM REGISTER;
동적 등록이 일반 운영의 표준이다. 인스턴스가 살아 있을 때만 등록되므로 정확하다. 정적 등록은 DB 미기동 상태 원격 startup이 필요한 경우(RMAN, Data Guard)에만 쓴다.
— 동적 우선, 정적은 보조
06 인접 TNS 에러와의 차이
TNS 연결 실패는 단계별로 다른 에러 코드로 표현된다. ORA-12541은 그중 "서버 응답 단계"의 실패다.
| 에러 | 실패 단계 | 전형적 시나리오 |
|---|---|---|
| ORA-12541 | 서버 응답 (리스너 미응답) | 리스너 죽음, 포트 차단, 비표준 포트 불일치 |
| ORA-12154 | 이름 해석 (클라이언트) | tnsnames.ora 별칭 누락·오타 |
| ORA-12514 | 서비스 등록 | 리스너는 살아 있지만 SERVICE_NAME 미등록 |
| ORA-12545 | 호스트 DNS | 호스트명이 IP로 변환 안 됨 |
| ORA-12170 | TCP 연결 타임아웃 | 방화벽·라우팅으로 응답 없음 |
| ORA-12560 | 프로토콜 어댑터 | Windows OracleService 미기동, ORACLE_SID 미설정 |
핵심 구분 ━ ORA-12541은 호스트 도달 후 리스너 응답 단계 실패이고, ORA-12154는 별칭 해석조차 못 한 클라이언트 단계 실패이며, ORA-12514는 리스너는 응답하지만 서비스명을 모르는 등록 단계 실패다.
07 자주 묻는 질문 5가지
Q1lsnrctl status는 정상인데 클라이언트만 ORA-12541이 발생한다
대부분 방화벽·보안 그룹 차단이다. 서버에서는 로컬 리스너에 도달해 정상으로 보이지만 외부에서는 포트가 막혀 있다. 클라이언트에서 nc로 포트 도달성을 확인하면 즉시 판단된다.
Q2리스너가 자주 죽는데 원인을 어떻게 추적하나
listener.log에 종료 시점과 일부 원인이 남는다. OOM Killer가 죽인 경우 dmesg에 기록된다. 메모리 부족·과부하·코어 덤프 여부를 함께 점검한다. systemd Restart=on-failure를 두면 장애 영향 시간을 크게 줄일 수 있다.
Q3동적 등록과 정적 등록 중 무엇이 더 좋은가
일반 운영에서는 동적이 표준이다. 인스턴스가 실제로 살아 있을 때만 등록되므로 정확하다. 정적 등록은 인스턴스가 죽은 상태에서도 리스너가 서비스를 "안다"고 응답하므로 원격 startup(RMAN duplicate, Data Guard 초기 구성)에만 사용한다.
Q4RAC SCAN 리스너에서 ORA-12541은 어떻게 처리되나
SCAN VIP는 3개 노드에 분산돼 있어 한 SCAN 리스너가 죽으면 클라이언트는 자동으로 다른 SCAN VIP로 시도한다. 그래도 ORA-12541이 발생하면 모든 SCAN 리스너가 죽었거나 클라이언트 DNS가 SCAN 이름을 정상 해석하지 못하는 상태다. srvctl status scan_listener와 nslookup scan-name으로 점검한다.
Q5Windows에서 ORA-12541과 ORA-12560은 어떻게 다른가
Windows의 OracleServiceXXX는 인스턴스를 관리하는 서비스다. 이게 죽어 있으면 ORA-12560(TNS:protocol adapter error)이 발생한다. ORA-12541은 리스너 자체의 응답 없음이다. Windows에서 ORA-12541을 만나면 OracleOraDB19Home1TNSListener 서비스 상태를 services.msc 또는 net start로 확인한다.
08 결론
ORA-12541은 데이터베이스 운영의 가장 기본적인 신호다 ━ "리스너가 응답하지 않는다." 진단 흐름은 단순하고 해결도 명확하다. 리스너를 다시 띄우거나, 방화벽을 열거나, 포트를 맞추면 끝난다.
실무 원칙은 다음과 같다.
첫째, 리스너를 살아 있게 유지하는 자동화가 본질적 예방책이다. systemd 자동 재시작 + 모니터링 알람을 기본 설정으로 둔다.
둘째, 서버 listener.ora와 클라이언트 tnsnames.ora의 HOST·PORT 일관성을 운영 변경 시마다 검증한다.
셋째, 같은 에러가 반복되면 자동 재시작 미설정·모니터링 부재·운영 절차 누락 같은 구조적 문제가 있을 가능성이 높다.
트러블슈팅 체크리스트
본 글은 Oracle Database 리스너 응답 실패 에러 ORA-12541의 일반적 원인과 해결 방법을 정리한 자료다. 운영 환경 적용 전 테스트 환경에서 충분히 검증한다.
#ORA12541 #TNSnolistener #오라클에러 #lsnrctl #listenerora #LOCALLISTENER #REMOTELISTENER #SCAN리스너 #RAC #동적등록 #LREG #방화벽 #ORA12154 #ORA12514 #ORA12560
댓글