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

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

이 글에서 다루는 내용

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

ORA-12518 TNS: listener could not hand off client connection 는?

ORA-12518 에러는 Oracle TNS 리스너(Listener)가 클라이언트의 접속 요청을 수신하였으나, 해당 연결을 Oracle 데이터베이스 서버 프로세스로 넘겨주지(Hand Off) 못할 때 발생하는 에러입니다. 주로 데이터베이스 서버의 프로세스 한계 초과, 리소스 부족, 또는 리스너와 데이터베이스 인스턴스 간의 통신 문제로 인해 발생합니다. 이 에러가 발생하면 클라이언트는 데이터베이스에 연결 자체가 불가능하므로, 운영 환경에서는 즉각적인 조치가 필요한 심각한 장애입니다.

주요 발생 원인

1. 데이터베이스 최대 프로세스 수(PROCESSES) 초과

Oracle 데이터베이스는 PROCESSES 파라미터로 동시에 허용할 수 있는 최대 프로세스 수를 제한합니다. 새로운 클라이언트 연결이 들어올 때 이 한계에 도달해 있으면, 리스너는 새 서버 프로세스를 생성하지 못하고 ORA-12518을 반환하게 됩니다. 이 원인이 가장 빈번하며, 특히 업무 피크 타임이나 배치 작업이 집중되는 시간대에 자주 발생합니다.

2. 운영체제(OS) 레벨의 리소스 부족

Oracle 서버 프로세스는 OS의 자원(메모리, 파일 디스크립터, 스왑 공간 등)을 사용합니다. OS의 사용 가능한 메모리가 부족하거나, 최대 오픈 파일 수(ulimit) 한계에 도달했거나, 스왑 영역이 고갈된 경우에도 새로운 서버 프로세스 생성이 실패하여 이 에러가 발생합니다. 이 경우 Oracle 로그뿐 아니라 OS 레벨의 시스템 로그(/var/log/messages, dmesg)도 함께 확인해야 합니다.

3. 리스너와 데이터베이스 인스턴스 간의 연동 문제

리스너가 기동된 상태이더라도, 데이터베이스 인스턴스가 정상적으로 리스너에 등록(Register)되지 않았거나, PMON 프로세스가 리스너와의 통신에 실패한 경우에도 ORA-12518이 발생할 수 있습니다. LOCAL_LISTENER 또는 REMOTE_LISTENER 파라미터 설정이 잘못되어 있거나, 리스너 자체가 비정상 상태일 때도 이 문제가 나타납니다.

해결 방법

원인 1: PROCESSES 파라미터 초과 해결

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

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

-- 현재 실제 사용 중인 프로세스 수 확인
SELECT COUNT(*) AS current_processes
FROM V$PROCESS;

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

-- PROCESSES 파라미터 한계 대비 사용률 확인
SELECT
    NAME,
    VALUE AS max_value,
    (SELECT COUNT(*) FROM V$PROCESS) AS current_usage,
    ROUND((SELECT COUNT(*) FROM V$PROCESS) / TO_NUMBER(VALUE) * 100, 2) AS usage_pct
FROM V$PARAMETER
WHERE NAME = 'processes';

현재 사용률이 80% 이상이라면 파라미터를 늘려야 합니다. PROCESSES는 동적 변경이 불가능하므로 재기동이 필요합니다.

-- SPFILE을 사용하는 경우 (재기동 후 적용)
ALTER SYSTEM SET PROCESSES = 500 SCOPE = SPFILE;

-- SESSIONS 파라미터는 PROCESSES에 연동되어 자동 조정되나, 명시적으로 설정 권장
-- 일반적으로 SESSIONS = PROCESSES * 1.1 + 5
ALTER SYSTEM SET SESSIONS = 555 SCOPE = SPFILE;

-- 변경 후 데이터베이스 재기동
SHUTDOWN IMMEDIATE;
STARTUP;

-- 재기동 후 파라미터 확인
SHOW PARAMETER PROCESSES;
SHOW PARAMETER SESSIONS;

원인 2: OS 리소스 부족 해결

OS 레벨에서 아래 명령어로 리소스 상태를 점검합니다.

# 메모리 및 스왑 사용량 확인
free -m

# Oracle 프로세스의 ulimit 확인 (oracle 유저로 실행)
ulimit -a

# 현재 오픈 파일 수 확인
lsof -u oracle | wc -l

# OS 커널 파라미터 확인
sysctl -a | grep -E "shmmax|shmmni|shmall|sem"

ulimit 설정이 부족한 경우 /etc/security/limits.conf를 수정합니다.

# /etc/security/limits.conf 에 아래 내용 추가 (예시)
oracle   soft   nofile   65536
oracle   hard   nofile   65536
oracle   soft   nproc    16384
oracle   hard   nproc    16384

Oracle 측에서는 SGA 및 PGA 크기를 점검합니다.

-- SGA 및 PGA 사용 현황 확인
SELECT
    NAME,
    ROUND(VALUE / 1024 / 1024, 2) AS size_mb
FROM V$PGASTAT
WHERE NAME IN ('total PGA inuse', 'total PGA allocated', 'maximum PGA allocated');

-- SGA 구성 요소별 크기 확인
SELECT POOL, NAME, ROUND(BYTES/1024/1024, 2) AS size_mb
FROM V$SGASTAT
ORDER BY BYTES DESC;

원인 3: 리스너 및 인스턴스 등록 문제 해결

리스너 상태와 서비스 등록 현황을 우선 확인합니다.

# 리스너 상태 확인
lsnrctl status

# 리스너 서비스 목록 확인
lsnrctl services

# 리스너 재기동
lsnrctl stop
lsnrctl start

데이터베이스에서 리스너 등록 파라미터를 확인하고 수동으로 재등록을 유도합니다.

-- LOCAL_LISTENER 파라미터 확인
SHOW PARAMETER LOCAL_LISTENER;

-- SERVICE_NAMES 파라미터 확인
SHOW PARAMETER SERVICE_NAMES;

-- PMON이 리스너에 서비스를 재등록하도록 강제
ALTER SYSTEM REGISTER;

-- 등록된 서비스 확인
SELECT NAME, NETWORK_NAME, CREATION_DATE
FROM V$SERVICES;

Alert 로그에서 에러 맥락을 파악하는 것도 중요합니다.

-- Alert 로그 위치 확인
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- 최근 에러 로그 조회 (Oracle 11g 이상)
SELECT ORIGINATING_TIMESTAMP, MESSAGE_TEXT
FROM V$DIAG_ALERT_EXT
WHERE MESSAGE_TEXT LIKE '%ORA-12518%'
   OR MESSAGE_TEXT LIKE '%listener%'
ORDER BY ORIGINATING_TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

예방 방법

1. 프로세스 및 세션 사용률 모니터링 자동화

임계값 기반의 선제적 알람 체계를 구축하여 ORA-12518이 발생하기 전에 조치할 수 있도록 해야 합니다. 아래 쿼리를 스케줄러에 등록하여 주기적으로 실행하고, 사용률이 80%를 초과하면 DBA에게 알람이 가도록 설정하는 것을 권장합니다.

-- 프로세스/세션 사용률 모니터링 쿼리 (Scheduler Job 또는 외부 모니터링 툴에 등록)
SELECT
    (SELECT VALUE FROM V$PARAMETER WHERE NAME = 'processes') AS max_processes,
    (SELECT COUNT(*) FROM V$PROCESS) AS current_processes,
    ROUND((SELECT COUNT(*) FROM V$PROCESS) /
          (SELECT TO_NUMBER(VALUE) FROM V$PARAMETER WHERE NAME = 'processes') * 100, 2)
          AS process_usage_pct,
    (SELECT VALUE FROM V$PARAMETER WHERE NAME = 'sessions') AS max_sessions,
    (SELECT COUNT(*) FROM V$SESSION) AS current_sessions,
    ROUND((SELECT COUNT(*) FROM V$SESSION) /
          (SELECT TO_NUMBER(VALUE) FROM V$PARAMETER WHERE NAME = 'sessions') * 100, 2)
          AS session_usage_pct
FROM DUAL;

2. Connection Pool 설정 최적화

애플리케이션 서버 측에서 Connection Pool의 최대 연결 수를 Oracle의 PROCESSES 한계에 맞게 적절히 설정해야 합니다. 모든 WAS(Web Application Server)의 최대 커넥션 합계가 Oracle PROCESSES 값의 70~80% 이내가 되도록 설계하고, Oracle Connection Manager(CMAN)나 Database Resident Connection Pooling(DRCP)을 활용하여 연결 수를 효율적으로 관리하면 근본적인 예방이 가능합니다.