[오라클 에러] ORA-12514 TNS:리스너가 서비스를 알지 못함 - 5가지 원인과 해결방법 (PDB 환경 포함)
테스트 환경: Oracle 12c / 19c / 21c / 23ai, Oracle Linux 8, Windows Server 2019
ORA-12514는 ORA-12541과 함께 오라클 접속 시 가장 자주 마주치는 에러입니다. 두 에러는 메시지가 비슷해서 자주 혼동되는데, 원인은 완전히 다릅니다.
- ORA-12541: 리스너 자체가 죽었거나 응답 안 함
- ORA-12514: 리스너는 살아있지만 요청한 서비스를 모름
특히 12c부터 도입된 멀티테넌트(CDB/PDB) 환경에서는 ORA-12514가 폭증했습니다. 19c 이상에서 운영 중인 환경이라면 더더욱 자주 만나는 에러입니다.
이번 글에서는 ORA-12514의 5가지 원인을 분류하고, PDB 환경 특화 이슈와 도메인(DB_DOMAIN) 미스매치까지 정리했습니다. 급하신 분은 빠른 진단 체크리스트부터 보세요.
에러 메시지 전문
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12514: TNS:리스너가 현재 접속 기술자에 요청된 서비스를 알지 못함
19c 이상에서는 더 자세한 정보가 함께 표시되기도 합니다.
ORA-12514: Cannot connect to database. Service sales_service.example.com is not registered
with the listener at host 10.9.7.5 port 1522. (CONNECTION_ID=...)
이 형식은 어떤 서비스명이 문제인지 명확히 알려주기 때문에 진단에 큰 도움이 됩니다.
ORA-12541 vs ORA-12514 - 한 표로 정리
두 에러가 헷갈리는 분들을 위한 핵심 비교표입니다.
항목 ORA-12541 ORA-12514
| 메시지 | 리스너가 없습니다 | 리스너가 서비스를 알지 못함 |
| 리스너 상태 | 죽음 / 응답 없음 | 살아있음 |
| lsnrctl status | 연결 실패 | 정상 출력 |
| telnet host 1521 | 실패 | 성공 |
| 핵심 원인 | 리스너 프로세스 자체 문제 | service_name 미등록 / 오기재 |
| PDB 환경 영향 | 영향 없음 | 매우 큼 |
| 해결 방향 | 리스너 시작 / 포트 / 방화벽 | service_name 확인 / PDB 상태 |
한 줄 진단법: 클라이언트에서 tnsping host:port 가 성공하는데 sqlplus 접속이 안 되면 ORA-12514, tnsping 자체가 실패하면 ORA-12541일 가능성이 큽니다.
빠른 진단 체크리스트
본격 해결 전에 30초 만에 원인을 좁히는 순서입니다.
- lsnrctl services 실행 → 리스너가 알고 있는 서비스 목록 확인
- 연결 문자열의 service_name 확인 → 위 목록에 있는가?
- PDB 환경이면 → PDB 상태 확인 (select name, open_mode from v$pdbs;)
- DB_DOMAIN 설정 확인 → 도메인 누락 가능성 (show parameter db_domain)
- 리스너 시작 직후 5분 이내라면 → 등록 대기 중일 수 있음
원인 1: service_name 오타 또는 누락 (가장 흔함)
ORA-12514의 70% 이상이 이 케이스입니다. 클라이언트의 tnsnames.ora에 적힌 SERVICE_NAME과 실제 DB의 서비스명이 다르면 발생합니다.
진단 방법
서버에서 리스너가 알고 있는 서비스 목록 확인:
lsnrctl services
출력 예시:
Services Summary...
Service "ORCL" has 1 instance(s).
Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "ORCLXDB" has 1 instance(s).
Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "pdbprod" has 1 instance(s).
Instance "ORCL", status READY, has 1 handler(s) for this service...
여기에 있는 서비스명만 접속 가능합니다.
클라이언트의 tnsnames.ora 확인:
PRODDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = pdbprod) ← 이 값이 lsnrctl services 결과에 있어야 함
)
)
service_name vs SID - 자주 혼동
신입 DBA가 가장 헷갈리는 부분입니다.
구분 SID SERVICE_NAME
| 의미 | 인스턴스 식별자 | 서비스 식별자 (논리적) |
| 멀티테넌트 | CDB만 가능 | PDB 접속에 필수 |
| 권장 | 레거시 호환용 | 신규 코드에서 권장 |
| 형식 (tnsnames) | (SID = ORCL) | (SERVICE_NAME = pdbprod) |
| 형식 (Easy Connect) | host:port:SID | host:port/service_name |
Easy Connect 표기법 차이를 보세요.
# SID 방식 (레거시)
sqlplus user/pw@192.168.10.5:1521:ORCL
# SERVICE_NAME 방식 (권장)
sqlplus user/pw@192.168.10.5:1521/pdbprod
: 와 / 의 차이로 SID인지 SERVICE_NAME인지가 결정됩니다.
해결 방법
lsnrctl services 결과의 정확한 서비스명을 그대로 사용하세요.
sqlplus user/pw@192.168.10.5:1521/pdbprod
원인 2: PDB가 OPEN 상태가 아님 (12c+ 멀티테넌트 특화) ★
이 케이스는 다른 한국어 블로그에서 거의 다루지 않는 영역입니다. 멀티테넌트 환경에서 ORA-12514가 발생하면 가장 먼저 의심해야 할 케이스입니다.
무엇이 문제인가
PDB는 OPEN 상태일 때만 자신의 서비스가 리스너에 자동 등록됩니다. PDB가 MOUNTED 상태로 머물러 있으면 해당 PDB의 service_name이 리스너에 보이지 않아 ORA-12514가 발생합니다.
DB가 재시작되면 PDB는 기본적으로 MOUNTED 상태로 올라오기 때문에, DB 재시작 직후 ORA-12514가 발생하는 가장 흔한 이유가 이 경우입니다.
진단 방법
CDB$ROOT에 접속해서 PDB 상태를 확인합니다.
sqlplus / as sysdba
SQL> SELECT name, open_mode, restricted FROM v$pdbs;
NAME OPEN_MODE RESTRICTED
------------ ------------ ----------
PDB$SEED READ ONLY NO
PDBPROD MOUNTED ← 이게 문제
PDBPROD가 MOUNTED 상태라면 리스너에서도 안 보입니다.
해결 방법
1) PDB를 OPEN 상태로 변경
ALTER PLUGGABLE DATABASE PDBPROD OPEN;
2) 다음 재시작 시에도 자동으로 OPEN되도록 영구 설정
ALTER PLUGGABLE DATABASE PDBPROD SAVE STATE;
이 설정을 하지 않으면 DB 재시작 때마다 PDB를 수동으로 OPEN해야 합니다. 운영 환경에서는 반드시 SAVE STATE를 적용하세요.
3) 모든 PDB 일괄 OPEN
ALTER PLUGGABLE DATABASE ALL OPEN;
실무 팁
DB 시작 트리거를 만들어 PDB 자동 OPEN을 보장하는 방법도 있지만, 12.1.0.2 이상에서는 위 SAVE STATE 명령이 표준 방법입니다. 트리거 방식보다 안전하고 권장됩니다.
원인 3: DB 인스턴스가 리스너에 등록 안 됨 (동적 등록 실패)
오라클은 DB 인스턴스가 시작될 때 PMON 프로세스가 리스너에 자신을 동적으로 등록합니다. 이 등록이 실패하면 리스너는 인스턴스의 존재를 모릅니다.
자주 발생하는 시나리오
- 리스너 시작 직후 1~2분 이내: 등록이 아직 완료되지 않은 일시적 상태 (잠시 기다리면 해결)
- 리스너 포트가 비표준 (1521이 아님): 인스턴스에 LOCAL_LISTENER 파라미터 설정 필요
- 리스너와 인스턴스가 다른 호스트: 동적 등록은 기본적으로 동일 호스트 가정
진단 방법
SQL> SHOW PARAMETER local_listener
SQL> SHOW PARAMETER service_names
PMON에게 강제로 재등록 요청:
SQL> ALTER SYSTEM REGISTER;
이 명령을 실행한 후 다시 lsnrctl services를 보면 서비스가 등록됩니다.
해결 방법: 비표준 포트 환경
리스너 포트가 1522처럼 1521이 아니라면, 인스턴스에 LOCAL_LISTENER 파라미터를 명시해야 합니다.
ALTER SYSTEM SET LOCAL_LISTENER =
'(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.5)(PORT=1522))'
SCOPE=BOTH;
ALTER SYSTEM REGISTER;
원인 4: DB_DOMAIN 미스매치 (19c 이상에서 흔함) ★
19c 이상 환경에서 service_name에 도메인이 붙는 경우가 일반적입니다.
무엇이 문제인가
DB_DOMAIN 파라미터가 example.com으로 설정되어 있으면, 인스턴스가 리스너에 등록하는 service_name은 자동으로 orcl.example.com처럼 도메인이 붙은 형태가 됩니다.
클라이언트가 SERVICE_NAME = orcl로만 요청하면 리스너는 "그런 서비스 없음"으로 응답합니다.
진단 방법
SQL> SHOW PARAMETER db_domain
SQL> SHOW PARAMETER service_names
lsnrctl services 결과와 클라이언트의 tnsnames.ora 값을 비교합니다.
# 서버에서 보이는 실제 서비스명
Service "orcl.example.com"
# 클라이언트가 요청하는 서비스명
SERVICE_NAME = orcl ← 도메인 누락
해결 방법
1) 클라이언트의 tnsnames.ora에 도메인 추가 (권장)
SERVICE_NAME = orcl.example.com
2) 또는 인스턴스의 service_names를 도메인 없이 등록
ALTER SYSTEM SET SERVICE_NAMES = 'orcl' SCOPE=BOTH;
ALTER SYSTEM REGISTER;
후자는 환경 표준에 따라 결정합니다. 운영 정책상 도메인을 유지해야 한다면 1번 방식으로 가세요.
원인 5: listener.ora 정적 등록 설정 오류
대부분의 환경에서는 동적 등록을 사용하지만, 정적 등록이 필요한 경우가 있습니다(예: 외부 프로시저 호출, RMAN 백업 카탈로그 접속).
정적 등록 vs 동적 등록
구분 동적 등록 정적 등록
| 누가 등록 | PMON 프로세스 (자동) | DBA가 listener.ora에 직접 작성 |
| DB 다운 시 | 자동 해제 | 등록 유지 (BLOCKED 상태로 보임) |
| 시작 시점 | DB 인스턴스 시작 시 | 리스너 시작 시 |
| 권장 | 일반적 운영 환경 | 특수 목적 (RMAN, 외부 프로시저) |
listener.ora 정적 등록 예시
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orcl)
(ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)
(SID_NAME = ORCL)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.5)(PORT = 1521))
)
자주 발생하는 실수
- GLOBAL_DBNAME을 클라이언트의 SERVICE_NAME과 다르게 입력
- SID_NAME을 잘못 입력 (실제 인스턴스명과 불일치)
- 정적 등록 후 리스너 미재시작 (lsnrctl reload 필요)
해결 방법
# 설정 변경 후 반드시 reload
lsnrctl reload
# 또는 재시작
lsnrctl stop
lsnrctl start
# 확인
lsnrctl services
빠른 해결 체크리스트
5분 안에 원인을 좁히는 종합 체크리스트입니다.
순서 확인 항목 명령어
| 1 | 리스너가 알고 있는 서비스 목록 | lsnrctl services |
| 2 | 클라이언트의 service_name 정확한가 | tnsnames.ora 확인 |
| 3 | PDB 환경이면 PDB 상태 확인 | SELECT name, open_mode FROM v$pdbs; |
| 4 | DB_DOMAIN 설정 | SHOW PARAMETER db_domain |
| 5 | 강제 재등록 시도 | ALTER SYSTEM REGISTER; |
이 5단계로 ORA-12514의 95% 이상이 해결됩니다.
그래도 안 풀린다면
위 5가지로도 해결되지 않는 드문 케이스:
- Data Guard 환경에서 Standby에 접속 시도: Standby의 service_names는 별도 등록이 필요
- RAC 환경의 SCAN 리스너 vs 로컬 리스너 혼동: SCAN 리스너로 접속해야 하는데 로컬 리스너 호스트로 접속 시도
- 리스너 시작 직후 5분 이내: 동적 등록 완료 전 일시적 ORA-12514. 잠시 후 자동 해결
- 방화벽이 1521만 열고 동적 포트 차단: 일부 환경에서 데이터 통신용 동적 포트가 별도 필요
마무리
ORA-12514는 "서비스를 모름"이라는 한 가지 증상이지만, 원인은 service_name 오타부터 PDB 상태, DB_DOMAIN 미스매치까지 다양합니다.
ORA-12541과 헷갈리지 않는 것이 진단의 첫 단추입니다. 리스너가 살아있는지 (lsnrctl status) 확인했다면 ORA-12541은 아니고, 그다음으로 어떤 서비스를 알고 있는지 (lsnrctl services) 확인하는 것이 핵심입니다.
특히 12c 이상 멀티테넌트 환경에서 DB 재시작 후 발생한 ORA-12514라면 90% 이상이 PDB가 MOUNTED 상태입니다. ALTER PLUGGABLE DATABASE ... SAVE STATE 한 줄로 재발을 영구 방지할 수 있습니다.
비슷한 케이스를 겪으셨거나, 위 방법으로도 해결되지 않은 상황이 있다면 댓글로 공유해 주세요. 함께 해결책을 찾아보겠습니다.