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

ORA-12519
2026년 09월 11일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-12519 TNS: no appropriate service handler found 는?

ORA-12519 에러는 Oracle 클라이언트가 데이터베이스 서버에 접속을 시도할 때, TNS 리스너가 해당 서비스 요청을 처리할 수 있는 적절한 핸들러를 찾지 못할 경우 발생하는 에러입니다. 주로 데이터베이스 서버의 최대 프로세스 수 또는 세션 수가 한계에 도달했거나, 서버 측의 부하가 극도로 높아져 새로운 연결을 수용할 수 없는 상태일 때 나타납니다. 이 에러는 운영 환경에서 갑작스러운 트래픽 급증이나 연결 누수(Connection Leak) 상황에서 자주 경험하게 되며, 신속한 원인 파악과 조치가 필요합니다.

주요 발생 원인

1. 최대 프로세스(PROCESSES) 또는 세션(SESSIONS) 파라미터 한계 초과

Oracle 데이터베이스는 동시에 연결할 수 있는 프로세스와 세션의 최대 수를 파라미터로 관리합니다. PROCESSES 파라미터가 설정된 한계에 도달하면 리스너는 더 이상 새로운 연결 요청을 수락할 수 없게 되어 ORA-12519 에러가 발생합니다. 특히 배치 작업이나 대규모 동시 접속이 발생하는 시간대에 주로 나타나며, 연결 풀 설정이 잘못된 애플리케이션에서도 빈번하게 발생합니다.

2. 연결 누수(Connection Leak)로 인한 좀비 세션 누적

애플리케이션 코드에서 사용한 데이터베이스 연결을 명시적으로 닫지 않거나, 예외 처리 로직이 미흡하여 연결이 정상적으로 반환되지 않을 경우 좀비 세션이 지속적으로 누적됩니다. 이러한 좀비 세션들이 PROCESSES 한도를 점유하게 되면 실질적으로 사용 가능한 연결 슬롯이 줄어들고, 결국 새로운 접속 요청을 거부하는 상황이 발생합니다. 장기간 운영 중인 시스템에서 특히 주의해야 하며 정기적인 세션 모니터링이 필수적입니다.

3. 리스너 설정 오류 또는 MTS(Multi-Threaded Server) 구성 문제

공유 서버(Shared Server, 구 MTS) 구성에서 DISPATCHERS 파라미터 설정이 부적절하거나, 리스너의 서비스 등록이 올바르게 이루어지지 않은 경우에도 이 에러가 발생할 수 있습니다. 리스너가 데이터베이스 서비스를 인식하지 못하거나, 서비스 핸들러 수가 부족하게 설정되어 있을 경우 연결 요청을 적절히 라우팅할 수 없게 됩니다. lsnrctl status 명령어로 서비스 핸들러 상태를 즉시 확인하는 것이 중요합니다.

해결 방법

원인 1 해결: PROCESSES 및 SESSIONS 파라미터 증가

먼저 현재 프로세스 및 세션 사용 현황을 확인합니다.

-- 현재 파라미터 설정값 확인
SHOW PARAMETER PROCESSES;
SHOW PARAMETER SESSIONS;

-- 현재 활성 세션 수 확인
SELECT COUNT(*) AS ACTIVE_SESSIONS
FROM V$SESSION
WHERE STATUS = 'ACTIVE';

-- 전체 세션 현황 요약
SELECT STATUS, COUNT(*) AS CNT
FROM V$SESSION
GROUP BY STATUS
ORDER BY CNT DESC;

-- PROCESSES 파라미터 상한에 얼마나 근접했는지 확인
SELECT RESOURCE_NAME,
       CURRENT_UTILIZATION,
       MAX_UTILIZATION,
       LIMIT_VALUE
FROM V$RESOURCE_LIMIT
WHERE RESOURCE_NAME IN ('processes', 'sessions');

한계에 도달한 것이 확인되면 파라미터를 증가시킵니다. 해당 파라미터는 정적(Static) 파라미터이므로 데이터베이스 재시작이 필요합니다.

-- PROCESSES 파라미터 증가 (예: 300으로 설정)
ALTER SYSTEM SET PROCESSES = 300 SCOPE = SPFILE;

-- SESSIONS는 PROCESSES 기반으로 자동 계산되지만 명시적 설정도 가능
-- SESSIONS = (PROCESSES * 1.1) + 5 공식 참고
ALTER SYSTEM SET SESSIONS = 335 SCOPE = SPFILE;

-- 변경 후 데이터베이스 재시작 (운영 환경에서는 유지보수 윈도우 활용)
SHUTDOWN IMMEDIATE;
STARTUP;

-- 재시작 후 적용 확인
SHOW PARAMETER PROCESSES;
SHOW PARAMETER SESSIONS;

원인 2 해결: 좀비 세션 정리 및 유휴 세션 타임아웃 설정

-- 장시간 비활성 상태인 세션 확인 (1시간 이상 유휴 상태)
SELECT SID,
       SERIAL#,
       USERNAME,
       STATUS,
       LAST_CALL_ET,
       MACHINE,
       PROGRAM,
       SQL_ID
FROM V$SESSION
WHERE STATUS = 'INACTIVE'
  AND LAST_CALL_ET > 3600
  AND USERNAME IS NOT NULL
ORDER BY LAST_CALL_ET DESC;

-- 특정 좀비 세션 강제 종료
ALTER SYSTEM KILL SESSION '&SID,&SERIAL#' IMMEDIATE;

-- 프로파일을 통한 유휴 세션 자동 종료 설정
-- 기존 프로파일 확인
SELECT PROFILE, RESOURCE_NAME, LIMIT
FROM DBA_PROFILES
WHERE RESOURCE_NAME IN ('IDLE_TIME', 'CONNECT_TIME')
ORDER BY PROFILE;

-- 새 프로파일 생성 또는 기존 프로파일 수정 (유휴 30분 후 자동 종료)
CREATE PROFILE APP_USER_PROFILE LIMIT
  IDLE_TIME    30
  CONNECT_TIME 480;

-- 기존 프로파일 수정
ALTER PROFILE DEFAULT LIMIT
  IDLE_TIME    60;

-- 사용자에게 프로파일 적용
ALTER USER app_user PROFILE APP_USER_PROFILE;

원인 3 해결: 리스너 상태 확인 및 서비스 재등록

-- 데이터베이스 서버에서 리스너 상태 확인 (OS 명령어)
-- lsnrctl status
-- lsnrctl services

-- 서비스 핸들러 수 동적 확인
SELECT NAME,
       NETWORK_NAME,
       CREATION_DATE,
       FAILED_COUNT,
       MIN_INSTANCES,
       MAX_INSTANCES
FROM V$SERVICES;

-- 디스패처 현황 확인 (공유 서버 환경)
SELECT NAME,
       NETWORK,
       STATUS,
       ACCEPT,
       MESSAGES,
       BYTES,
       CREATED,
       IDLE,
       BUSY
FROM V$DISPATCHER;

-- 리스너에 서비스 강제 재등록
ALTER SYSTEM REGISTER;

-- 공유 서버 디스패처 수 동적 증가
ALTER SYSTEM SET DISPATCHERS = '(PROTOCOL=TCP)(DISPATCHERS=5)';

예방 방법

1. V$RESOURCE_LIMIT 기반 주기적 모니터링 및 알림 체계 구축

운영 환경에서는 PROCESSES, SESSIONS 등의 리소스 사용률이 임계치(예: 80%)를 초과할 경우 자동으로 알림이 발송되도록 모니터링 체계를 구축해야 합니다. Oracle Enterprise Manager(OEM) 또는 Zabbix, Prometheus 등의 외부 모니터링 툴과 연동하여 아래 쿼리를 주기적으로 실행하고, 사전에 파라미터를 증설할 수 있도록 운영 프로세스를 정립하는 것이 중요합니다.

-- 리소스 사용률 80% 초과 항목 감지 쿼리 (모니터링 스크립트에 활용)
SELECT RESOURCE_NAME,
       CURRENT_UTILIZATION,
       MAX_UTILIZATION,
       TO_NUMBER(LIMIT_VALUE) AS LIMIT_VALUE,
       ROUND(CURRENT_UTILIZATION / TO_NUMBER(LIMIT_VALUE) * 100, 2) AS USAGE_PCT
FROM V$RESOURCE_LIMIT
WHERE LIMIT_VALUE != 'UNLIMITED'
  AND TO_NUMBER(LIMIT_VALUE) > 0
  AND ROUND(CURRENT_UTILIZATION / TO_NUMBER(LIMIT_VALUE) * 100, 2) >= 80
ORDER BY USAGE_PCT DESC;

2. 애플리케이션 레벨 커넥션 풀 설정 최적화 및 연결 누수 방지

애플리케이션에서 JDBC Connection Pool(HikariCP, DBCP 등) 또는 Oracle UCP(Universal Connection Pool)를 올바르게 설정하여 최대 연결 수가 데이터베이스의 PROCESSES 한도를 초과하지 않도록 반드시 관리해야 합니다. 또한 CONNECTION_VALIDATION, INACTIVE_CONNECTION_TIMEOUT 등의 옵션을 활성화하여 좀비 연결이 풀에 잔류하지 않도록 하고, 코드 리뷰를 통해 try-with-resources 패턴 사용을 강제하는 개발 표준을 수립하는 것이 장기적으로 효과적입니다.