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

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

이 글에서 다루는 내용

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

ORA-12152 TNS: unable to send break message 는?

ORA-12152 에러는 Oracle Net Services(TNS) 레이어에서 클라이언트가 서버로 “break message”(중단 신호)를 전송하지 못할 때 발생하는 네트워크 수준의 에러입니다. 이 에러는 주로 사용자가 실행 중인 쿼리나 작업을 강제로 취소(Ctrl+C)하거나, 애플리케이션이 세션을 비정상적으로 종료하려 할 때 TNS 통신 채널에 문제가 있어 해당 신호를 서버에 전달하지 못하는 상황에서 나타납니다. 결과적으로 클라이언트와 서버 간의 연결이 불안정한 상태로 남게 되어 세션 고아(orphan session) 문제나 리소스 누수로 이어질 수 있습니다.

주요 발생 원인

1. 네트워크 인프라 문제 (방화벽, 로드밸런서, 프록시)

가장 흔한 원인으로, 방화벽이나 로드밸런서가 TCP 연결의 중간에 끼어들어 break message 패킷을 차단하거나 변조하는 경우입니다. 특히 AWS ELB, F5, Cisco ASA 같은 장비들이 idle 상태의 TCP 세션을 임의로 끊거나, OOB(Out-Of-Band) 데이터 전송을 지원하지 않을 때 이 에러가 발생합니다. Oracle Net의 break message는 기본적으로 TCP OOB(Urgent 플래그) 방식으로 전송되기 때문에, 이를 지원하지 않는 네트워크 장비와 조합될 경우 즉시 문제가 됩니다.

2. sqlnet.ora 파라미터 설정 오류 또는 미설정

sqlnet.ora 파일에서 DISABLE_OOB 파라미터가 올바르게 설정되지 않았거나, 클라이언트와 서버 측 설정이 불일치하는 경우 이 에러가 발생합니다. 예를 들어 서버 측은 OOB를 활성화한 상태인데 클라이언트 측 네트워크 장비가 OOB를 차단한다면, 중단 신호를 보내는 시점에 TNS 통신이 실패합니다. 이 파라미터 하나의 설정 불일치가 실무 환경에서 수많은 ORA-12152를 유발하는 핵심 원인 중 하나입니다.

3. Oracle Net 리스너 또는 서버 프로세스 이상

리스너(Listener)가 비정상 상태이거나, 서버 프로세스(Shadow Process)가 응답 불가 상태에 빠진 경우에도 이 에러가 발생할 수 있습니다. 클라이언트가 break message를 전송하더라도 서버 측 프로세스가 이를 수신하고 처리할 수 없는 상태라면 TNS 레이어에서 에러를 반환합니다. 리스너 로그를 확인하면 이 경우 해당 시점에 TNS-12535, TNS-00505 같은 타임아웃 관련 에러가 함께 기록되어 있는 경우가 많습니다.

해결 방법

원인 1 해결: DISABLE_OOB 파라미터 설정

클라이언트와 서버 양쪽의 sqlnet.ora에 아래 파라미터를 추가하여 OOB 방식 대신 인밴드(In-Band) 방식으로 break message를 전송하도록 변경합니다. 이 방법이 가장 즉각적인 해결책입니다.

-- 클라이언트 및 서버 sqlnet.ora 파일에 아래 항목 추가
-- 위치: $ORACLE_HOME/network/admin/sqlnet.ora

DISABLE_OOB = ON

설정 후 리스너를 재시작하고 연결을 새로 맺어야 적용됩니다.

-- 리스너 재시작 (OS 명령어)
-- lsnrctl stop
-- lsnrctl start

-- 설정 확인: 현재 세션의 네트워크 파라미터 확인
SELECT network_service_banner
FROM v$session_connect_info
WHERE sid = SYS_CONTEXT('USERENV', 'SID');

원인 2 해결: 세션 상태 확인 및 고아 세션 정리

에러 발생 후 서버에 고아 세션이 남아있을 수 있으므로 아래 쿼리로 확인하고 정리합니다.

-- 비정상 세션 확인
SELECT s.sid,
       s.serial#,
       s.username,
       s.status,
       s.machine,
       s.program,
       s.last_call_et AS seconds_since_last_call
FROM   v$session s
WHERE  s.status = 'INACTIVE'
AND    s.last_call_et > 3600  -- 1시간 이상 비활성 세션
ORDER  BY s.last_call_et DESC;

-- 특정 고아 세션 강제 종료
ALTER SYSTEM KILL SESSION '&sid, &serial#' IMMEDIATE;

-- 세션별 현재 대기 이벤트 확인 (문제 세션 식별)
SELECT s.sid,
       s.serial#,
       s.username,
       w.event,
       w.wait_time,
       w.seconds_in_wait
FROM   v$session s
JOIN   v$session_wait w ON s.sid = w.sid
WHERE  w.event LIKE '%SQL*Net%'
OR     w.event LIKE '%TNS%'
ORDER  BY w.seconds_in_wait DESC;

원인 3 해결: 리스너 상태 점검 및 복구

-- 리스너 상태 확인 (OS 명령어 후 결과를 SQL로 활용)
-- lsnrctl status
-- lsnrctl services

-- 현재 DB에 등록된 서비스 확인
SELECT name, network_name, creation_date
FROM   v$active_services
ORDER  BY name;

-- 리스너에 서비스 수동 등록 (필요 시)
-- EXECUTE DBMS_SERVICE.START_SERVICE('서비스명');

-- 프로세스 상태 점검
SELECT program,
       COUNT(*) AS process_count
FROM   v$process
GROUP  BY program
ORDER  BY process_count DESC;

sqlnet.ora 전체 권장 설정 예시

-- $ORACLE_HOME/network/admin/sqlnet.ora 권장 설정
-- (주석은 실제 파일에서 제거 후 사용)

SQLNET.EXPIRE_TIME = 10          -- 데드 커넥션 감지 (분 단위)
DISABLE_OOB = ON                 -- OOB 비활성화 (방화벽 환경)
SQLNET.RECV_TIMEOUT = 60         -- 수신 타임아웃 (초 단위)
SQLNET.SEND_TIMEOUT = 60         -- 송신 타임아웃 (초 단위)
TCP.CONNECT_TIMEOUT = 15         -- TCP 연결 타임아웃 (초 단위)

예방 방법

1. Dead Connection Detection(DCD) 및 SQLNET.EXPIRE_TIME 설정

클라이언트가 비정상 종료되었을 때 서버 측에서 이를 감지하고 세션을 자동으로 정리할 수 있도록 SQLNET.EXPIRE_TIME 파라미터를 sqlnet.ora에 반드시 설정하세요. 이 값을 10~30분 범위로 설정하면 고아 세션이 자동으로 제거되어 ORA-12152 발생 후의 후속 문제를 예방할 수 있습니다. 더불어, 애플리케이션 레벨에서 커넥션 풀(Connection Pool)의 validation query와 testOnBorrow 옵션을 활성화하여 연결 유효성을 주기적으로 검증하는 것이 Best Practice입니다.

2. 네트워크 장비와의 호환성 사전 검증 및 표준화

신규 네트워크 장비(방화벽, 로드밸런서) 도입 시 Oracle Net의 OOB 지원 여부를 반드시 사전에 검증하고, DISABLE_OOB = ON 설정을 표준 sqlnet.ora 템플릿에 포함시켜 전사 표준으로 배포하세요. 또한 방화벽의 TCP idle timeout 값을 Oracle의 SQLNET.EXPIRE_TIME보다 크게 설정하여 세션이 방화벽에 의해 먼저 끊기는 상황을 방지하는 것이 중요합니다.