[오라클 에러] ORA-12541 TNS 리스너가 없습니다 - 5가지 원인과 해결방법 (실무 DBA 정리)
테스트 환경: Oracle 19c / Windows Server 2019 / Oracle Linux 8
오라클 접속 시 가장 자주 마주치는 에러 중 하나가 바로 ORA-12541입니다. 어제까지 멀쩡히 접속되던 DB에 갑자기 연결이 안 되거나, 신규 클라이언트에서 접속이 안 될 때 이 에러가 뜹니다.
실무에서 운영 DB를 관리하면서 이 에러를 수십 번 마주쳤는데, 원인이 의외로 다양합니다. 단순히 "리스너 재시작"만으로 해결되지 않는 경우도 많아서, 이번 글에서는 5가지 원인을 분류하고 각각의 해결 방법까지 정리했습니다.
급하신 분은 아래 빠른 해결 순서부터 보세요.
에러 메시지 전문
ORA-12541: TNS:리스너가 없습니다
ORA-12541: TNS:no listener
SQL*Plus, SQL Developer, Toad, 그리고 애플리케이션 로그 등 어디에서나 이 메시지가 동일하게 나타납니다. 한글 환경에서는 한글로, 영문 환경에서는 영문으로 표시됩니다.
ORA-12541은 왜 발생할까?
한 줄로 정리하면 "클라이언트가 리스너에 접속을 시도했지만, 해당 위치에 리스너가 응답하지 않는 상태" 입니다.
오라클은 클라이언트와 DB 인스턴스 사이에 리스너(Listener) 라는 중간 프로세스가 통신을 중개합니다. 이 리스너가 죽었거나, 클라이언트가 잘못된 곳을 두드리고 있으면 ORA-12541이 발생합니다.
원인은 크게 5가지로 나눌 수 있습니다.
- 리스너 서비스 자체가 죽음
- listener.log 파일이 4GB를 초과 (Windows 환경에서 자주 발생)
- 방화벽이 1521 포트를 차단
- tnsnames.ora의 HOST 값이 잘못됨
- 다른 프로세스가 1521 포트를 점유
하나씩 해결 방법을 보겠습니다.
< 원인 1> 리스너 서비스 자체가 죽음 (가장 흔함)
진단 방법
서버에 접속해서 리스너 상태를 확인합니다.
lsnrctl status
리스너가 정상이면 다음과 같이 STATUS of the LISTENER와 함께 등록된 서비스 목록이 출력됩니다.
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 19.0.0.0.0
Start Date 28-MAY-2026 09:15:23
Uptime 0 days 5 hr. 12 min. 8 sec
만약 리스너가 죽었다면 아래와 같은 메시지가 나옵니다.
TNS-12541: TNS:리스너가 없습니다
TNS-12560: TNS:프로토콜 어댑터 오류
TNS-00511: 리스너가 없습니다
해결 방법
Linux/Unix 환경
# oracle 계정으로 실행
lsnrctl start
Windows 환경
Win + R → services.msc 입력 → OracleOraDB19Home1TNSListener 같은 이름의 서비스를 찾아 시작을 누릅니다.
또는 관리자 권한 cmd에서:
net start OracleOraDB19Home1TNSListener
서비스 이름은 오라클 버전과 설치 옵션에 따라 다릅니다. Oracle...TNSListener로 시작하는 이름을 찾으세요.
실무 팁
운영 환경에서 리스너가 갑자기 죽었다면 단순히 재시작만 하지 말고 죽은 원인부터 확인하세요. 그냥 살려두면 며칠 뒤 똑같이 죽습니다. 다음 항목인 listener.log 확인이 첫 번째 해야 할 일입니다.
< 원인 2> listener.log 파일이 4GB 초과 (간과하기 쉬운 케이스)
이건 Windows 32bit 환경 또는 일부 파일시스템 제약이 있는 환경에서 발생합니다. listener.log 파일이 4GB를 넘으면 리스너가 로그를 더 쓸 수 없어서 자체적으로 죽거나, 죽은 것처럼 응답하지 않는 상태가 됩니다.
운영한 지 오래된 DB 서버에서 "어느 날 갑자기" ORA-12541이 발생한다면 이걸 가장 먼저 의심하세요.
진단 방법
listener.log 위치는 lsnrctl status의 출력에서 확인할 수 있습니다.
Listener Log File /app/oracle/diag/tnslsnr/서버명/listener/alert/log.xml
또는 기본 경로:
- Linux: $ORACLE_BASE/diag/tnslsnr/{호스트명}/listener/trace/listener.log
- Windows: %ORACLE_BASE%\diag\tnslsnr\{호스트명}\listener\trace\listener.log
해당 파일 크기를 확인해서 4GB에 가깝거나 초과했다면 원인이 맞습니다.
해결 방법
1) 리스너 중지
lsnrctl stop
2) listener.log 백업 후 삭제 (또는 이름 변경)
# Linux
mv listener.log listener.log.20260528.bak
# Windows
ren listener.log listener.log.20260528.bak
3) 리스너 재시작
lsnrctl start
재발 방지 (★ 실무 핵심)
이게 한 번 발생했다면 다음에 또 발생합니다. 영구 해결을 위해 로그 로테이션을 자동화해야 합니다.
가장 간단한 방법은 ADRCI(Automatic Diagnostic Repository Command Interpreter)로 보관 정책을 설정하는 것입니다.
adrci
ADRCI> show homes
ADRCI> set home diag/tnslsnr/{호스트명}/listener
ADRCI> set control (SHORTP_POLICY = 168, LONGP_POLICY = 720)
SHORTP_POLICY는 시간 단위(기본 720시간=30일), LONGP_POLICY는 일 단위(기본 8760시간=365일)입니다. 위 예시는 trace를 7일, alert를 30일만 보관합니다.
또는 더 간단하게, listener.ora에 로깅 비활성화 옵션을 줘서 트래픽 로그를 최소화할 수도 있습니다(단, 보안 감사가 필요한 환경에서는 비추천).
LOGGING_LISTENER = OFF
< 원인 3> 방화벽이 1521 포트를 차단
신규로 구축한 서버, 또는 보안 정책 변경 직후에 자주 발생합니다. 리스너는 살아있는데 클라이언트의 패킷이 서버까지 도달하지 못하는 상황입니다.
진단 방법
클라이언트에서 telnet으로 포트 도달 여부 확인
telnet {DB서버 IP} 1521
연결이 즉시 끊기거나 "연결할 수 없습니다"가 나오면 방화벽 문제일 가능성이 큽니다.
서버에서 포트 LISTEN 상태 확인
# Linux
netstat -tlnp | grep 1521
ss -tlnp | grep 1521
# Windows
netstat -ano | findstr 1521
0.0.0.0:1521 또는 *:1521로 LISTEN 상태가 보이면 서버는 정상이고, 방화벽이 막은 겁니다.
해결 방법
Linux (firewalld)
sudo firewall-cmd --permanent --add-port=1521/tcp
sudo firewall-cmd --reload
Linux (iptables)
sudo iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
sudo service iptables save
Windows
Windows Defender 방화벽 → 고급 설정 → 인바운드 규칙 → 새 규칙 → 포트 → TCP / 1521
회사 네트워크 방화벽이 막는 경우라면 인프라 팀에 1521 포트 오픈 요청을 해야 합니다.
< 원인 4> tnsnames.ora의 HOST 값이 잘못됨
클라이언트의 tnsnames.ora 파일에 적힌 HOST가 잘못되어 있으면, 엉뚱한 곳을 두드리니 당연히 ORA-12541이 납니다.
특히 다음 케이스에서 자주 발생합니다.
- 서버 IP가 변경되었는데 tnsnames.ora를 안 고침
- localhost로 설정했지만 다른 PC에서 접속 시도
- DNS 환경이라 호스트명이 변경됨
진단 방법
클라이언트 tnsnames.ora 위치:
- Windows: %ORACLE_HOME%\network\admin\tnsnames.ora
- Linux: $ORACLE_HOME/network/admin/tnsnames.ora
파일을 열어서 접속하려는 TNS 별칭의 HOST 값을 확인합니다.
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)
해결 방법
1) tnsping으로 별칭 동작 확인
tnsping ORCL
확인(10밀리초) 같은 응답이 나오면 정상. 안 나오면 HOST/PORT를 의심합니다.
2) HOST를 실제 IP로 수정
localhost로 되어 있다면 실제 서버 IP나 호스트명으로 변경합니다.
3) ping으로 IP 도달 여부 추가 확인
ping 192.168.10.5
실무 팁
서버 마이그레이션 직후 클라이언트마다 tnsnames.ora를 일일이 고치는 게 번거롭다면, DNS에 별칭을 만들어 두는 방식을 권장합니다. 이렇게 하면 IP가 바뀌어도 DNS만 갱신하면 끝입니다.
< 원인 5> 다른 프로세스가 1521 포트를 점유
흔하지는 않지만, 1521 포트를 다른 프로세스가 먼저 점유한 경우 리스너가 시작 자체를 못 합니다.
진단 방법
# Linux
sudo lsof -i :1521
sudo netstat -tlnp | grep 1521
# Windows
netstat -ano | findstr 1521
tasklist | findstr {PID}
tnslsnr 또는 TNSLSNR.exe 외의 다른 프로세스가 1521을 잡고 있다면 그게 원인입니다.
해결 방법
가장 흔한 시나리오는 이전에 종료된 리스너의 좀비 프로세스가 남아있는 경우입니다. 해당 PID를 강제 종료합니다.
# Linux
sudo kill -9 {PID}
# Windows (관리자 권한)
taskkill /F /PID {PID}
만약 다른 정상 서비스가 1521을 쓰고 있다면, 오라클 리스너의 포트를 변경하는 것이 안전합니다. listener.ora에서 포트를 1522 등으로 변경하고, 클라이언트의 tnsnames.ora도 같이 변경합니다.
빠른 해결 체크리스트
5분 안에 원인을 좁히는 순서입니다.
- 서버에서 lsnrctl status 실행 → 리스너 살아있나?
- 죽었으면 → 원인 1 또는 2
- 클라이언트에서 telnet {IP} 1521 → 포트 도달하나?
- 안 되면 → 원인 3
- tnsping {별칭} 실행 → 별칭 해석되나?
- 실패면 → 원인 4
- listener.log 파일 크기 → 4GB 근처인가?
- 그렇다면 → 원인 2 (이 케이스는 한 번 터지면 또 터집니다)
- netstat으로 1521 점유 프로세스 확인 → tnslsnr 맞나?
- 다른 프로세스면 → 원인 5
그래도 안 풀린다면
위 5가지로도 해결되지 않는 드문 케이스:
- Windows 사용자명에 한글/공백 포함: 오라클이 환경변수 해석을 못 하는 경우가 있습니다. 사용자명 변경 또는 별도 계정 생성으로 해결됩니다.
- ORACLE_HOME 환경변수가 잘못 설정됨: 여러 오라클 버전을 설치한 환경에서 발생. echo $ORACLE_HOME(Linux) 또는 echo %ORACLE_HOME%(Windows)으로 확인.
- 호스트명이 IP로 풀리지 않음: /etc/hosts 또는 Windows hosts 파일에 호스트명-IP 매핑 추가.
마무리
ORA-12541은 결국 "리스너에 접속이 안 됨" 이라는 한 가지 증상이지만, 원인은 서버, 네트워크, 클라이언트 설정 어디서나 발생할 수 있습니다. 무작정 리스너 재시작부터 하기보다는, 위 체크리스트 순서대로 진단하시면 5분 안에 원인을 찾을 수 있습니다.
특히 운영 환경에서 갑자기 발생한 경우 원인 2(listener.log 4GB) 를 가장 먼저 확인하세요. 재발률이 가장 높은 케이스입니다.
비슷한 케이스를 겪으셨거나, 위 방법으로도 해결이 안 되는 상황이 있다면 댓글로 공유해 주세요. 함께 해결책을 찾아보겠습니다.
관련 글
'DBA 실무 > Oracle(오라클)' 카테고리의 다른 글
| 오라클(Oracle) 데이터 타입 (0) | 2024.08.12 |
|---|