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

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

이 글에서 다루는 내용

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

ORA-12542 TNS: address already in use 는?

ORA-12542 에러는 Oracle Net Services(TNS)가 리스너를 특정 포트와 주소에 바인딩하려 할 때, 해당 주소와 포트가 이미 다른 프로세스에 의해 사용 중일 경우 발생하는 네트워크 레벨의 에러입니다. 주로 Oracle Listener를 시작(start)하거나 재시작(restart)하는 과정에서 발생하며, 기존 리스너 프로세스가 완전히 종료되지 않은 상태에서 새 리스너를 기동하려 할 때 자주 목격됩니다. 이 에러는 데이터베이스 자체의 문제가 아닌 네트워크 소켓 및 OS 레벨의 포트 충돌 문제이기 때문에, DBA라면 반드시 OS 명령어와 Oracle 관리 도구를 함께 활용하여 진단해야 합니다.

주요 발생 원인

1. 기존 리스너 프로세스가 좀비(Zombie) 상태로 잔존

가장 흔한 원인으로, lsnrctl stop 명령 실행 후 리스너 프로세스가 OS 레벨에서 완전히 종료되지 않고 좀비 상태로 남아 있는 경우입니다. 이 상태에서 lsnrctl start를 실행하면 1521 포트가 여전히 점유된 상태이기 때문에 ORA-12542가 발생합니다. 특히 RAC 환경이나 네트워크 불안정 상황에서 강제 종료(kill -9) 후에 이런 현상이 빈번하게 나타납니다.

2. 동일 포트를 사용하는 다른 애플리케이션 또는 중복 리스너 기동

Oracle 리스너의 기본 포트인 1521번을 다른 애플리케이션(예: 방화벽 소프트웨어, 보안 에이전트, 또는 다른 Oracle 인스턴스의 리스너)이 선점하고 있는 경우에도 이 에러가 발생합니다. 특히 다중 Oracle Home이 설치된 서버에서 각 Oracle Home마다 별도의 리스너를 운영할 경우, listener.ora 설정이 잘못되어 동일 포트를 두 리스너가 동시에 사용하려는 상황이 발생할 수 있습니다. 이런 경우 단순히 리스너를 재시작하는 것만으로는 해결되지 않으며 반드시 포트 충돌 원인을 정확히 파악해야 합니다.

3. listener.ora 설정 오류 또는 이전 설정 파일 잔존

$ORACLE_HOME/network/admin/listener.ora 파일에 잘못된 HOST 또는 PORT 정보가 기재되어 있거나, 이전 Oracle 버전 업그레이드/마이그레이션 과정에서 구 설정 파일이 삭제되지 않고 남아 있는 경우입니다. 특히 IP 주소나 호스트명이 변경된 서버에서 listener.ora를 업데이트하지 않으면, 존재하지 않는 주소로 바인딩을 시도하거나 잘못된 포트 설정으로 인해 에러가 발생할 수 있습니다. 이 경우 에러 메시지만 보고 단순 포트 충돌로 오판하기 쉽기 때문에 설정 파일 검토가 필수입니다.

해결 방법

해결책 1: 기존 리스너 프로세스 확인 및 강제 종료

먼저 현재 리스너 상태를 확인하고, OS 레벨에서 포트를 점유 중인 프로세스를 식별합니다.

-- 리스너 상태 확인 (OS 명령어)
-- lsnrctl status LISTENER

-- Oracle 세션에서 리스너 연결 상태 조회
SELECT s.sid, s.serial#, s.username, s.status, s.machine, s.program
FROM v$session s
WHERE s.program LIKE '%TNS%'
   OR s.machine LIKE '%listener%';

OS 레벨에서 포트 점유 프로세스를 확인하고 종료합니다.

-- [Linux/Unix] 1521 포트 사용 프로세스 확인 후 종료
-- netstat -tlnp | grep 1521
-- lsof -i :1521
-- ss -tlnp | grep 1521
-- kill -9 <PID>

-- [Windows] 포트 확인
-- netstat -ano | findstr :1521
-- taskkill /PID <PID> /F

-- 프로세스 종료 후 리스너 재기동
-- lsnrctl start LISTENER

-- 리스너 기동 후 상태 확인
-- lsnrctl status LISTENER

-- DB 접속 테스트
SELECT instance_name, status, host_name
FROM v$instance;

해결책 2: 포트 충돌 원인 파악 및 listener.ora 수정

1521 포트를 사용 중인 다른 프로세스가 있다면, listener.ora에서 포트를 변경하거나 충돌 프로세스를 중단합니다.

-- listener.ora 설정 예시 (포트 변경: 1521 -> 1522)
/*
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = mydbserver)(PORT = 1522))
    )
  )
*/

-- tnsnames.ora도 함께 수정 필요
/*
ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbserver)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )
*/

-- 포트 변경 후 리스너 재기동 및 동적 등록 확인
-- lsnrctl stop
-- lsnrctl start
-- lsnrctl services LISTENER

-- DB에서 리스너 등록 서비스 확인
SELECT name, network_name
FROM v$active_services
ORDER BY name;

해결책 3: listener.ora 설정 검증 및 재구성

설정 파일 오류가 의심될 경우 아래와 같이 검증합니다.

-- 현재 DB의 리스너 설정 관련 파라미터 확인
SHOW PARAMETER local_listener;
SHOW PARAMETER remote_listener;

-- 로컬 리스너 주소 직접 설정 (동적 등록 강제)
ALTER SYSTEM SET local_listener =
  '(ADDRESS=(PROTOCOL=TCP)(HOST=mydbserver)(PORT=1521))' SCOPE=BOTH;

-- 리스너 등록 갱신 (DB 내부에서 실행)
ALTER SYSTEM REGISTER;

-- 실제 리스너에 등록된 서비스 목록 확인
SELECT endpoint_count, refused_count
FROM v$listener_network;

-- 현재 등록된 서비스 확인
SELECT name, db_unique_name, con_id
FROM v$services
ORDER BY name;

예방 방법

1. 리스너 기동/중단 절차 표준화 및 스크립트 자동화

리스너 재시작 시 단순히 stop/start를 반복하는 것이 아니라, stop 후 반드시 OS 레벨에서 프로세스 잔존 여부를 확인하는 절차를 표준 운영 절차(SOP)에 포함시켜야 합니다. 아래와 같은 쉘 스크립트를 활용하면 리스너 종료 후 포트 클리어 여부를 자동으로 확인하고 안전하게 재기동할 수 있습니다.

-- 리스너 재기동 전 잔존 프로세스 확인을 위한 SQL 모니터링
-- (DBA_HIST 활용한 리스너 관련 이벤트 조회)
SELECT snap_id, event_name, total_waits, time_waited_micro
FROM dba_hist_system_event
WHERE event_name LIKE '%SQL*Net%'
  AND snap_id = (SELECT MAX(snap_id) FROM dba_hist_snapshot)
ORDER BY time_waited_micro DESC;

2. 포트 모니터링 및 알림 체계 구축

Oracle Enterprise Manager(OEM) 또는 별도의 모니터링 툴을 활용하여 리스너 포트(기본 1521)의 가용성을 주기적으로 체크하고, 포트 응답이 없거나 이중 바인딩 시도가 감지될 경우 즉시 DBA에게 알림이 가도록 임계값을 설정해야 합니다. 또한 서버 재부팅 시 Oracle 리스너가 다른 애플리케이션보다 먼저 기동되지 않도록 OS 서비스 기동 순서(startup sequence)를 명확히 정의해 두면 포트 충돌을 사전에 방지할 수 있습니다.