접속 아키텍처: Listener·Service·Session·Dedicated·Shared Server

핵심 요약

Oracle 접속 아키텍처는 통신 경로, 논리 상태, 업무 이름, 접속 중개, SQL 실행 주체를 분리해서 이해해야 합니다.

Connection
→ Client와 Database 사이의 통신 경로

Session
→ 인증 후 Database 안에 유지되는 논리 작업 상태

Service
→ Application Workload를 나타내는 논리 접속 이름

Listener
→ 최초 접속 요청을 등록된 Service Handler로 연결

Server Process
→ Parse·Execute·Fetch·Commit 요청을 실제 처리

일반적인 접속 흐름은 다음과 같습니다.

Client
→ Connect Descriptor의 Listener 주소와 SERVICE_NAME 사용
→ Listener가 Service와 Handler 상태 확인
→ Dedicated Server·Dispatcher·Pooled Server 중 적합한 Handler 선택
→ Client가 Database와 직접 통신
→ 인증 후 Session 생성
→ Database Call 단위로 SQL 처리

Listener는 접속을 설정한 뒤 일반 SQL의 Parse·Execute·Fetch 경로에서 빠집니다. Connection Pool은 이미 만든 Physical Connection을 재사용해 접속 비용을 줄이는 동시에 Database로 진입하는 동시 작업 수를 제한합니다.

학습 목표

• Connection·Session·Database Call을 서로 다른 단위로 설명한다.
• Service·Instance·SID·Net Service Name을 혼동하지 않는다.
• Listener·LREG·Service Handler의 접속 설정 역할을 설명한다.
• Dedicated Server·Shared Server·DRCP의 자원 재사용 단위를 비교한다.
• Dispatcher·Virtual Circuit·Request Queue·Response Queue의 흐름을 설명한다.
• Application Connection Pool의 Logical·Physical Connection을 구분한다.
• Pool 반환 시 Transaction과 Session State를 정리해야 하는 이유를 설명한다.
• Oracle 26ai의 Multi-Pool DRCP와 RESET_STATE 적용 범위를 이해한다.
• Listener·Service·Session·Process·Shared Server Queue를 단계적으로 진단한다.

1. Connection·Session·Database Call

1.1 Connection

Connection은 Client와 Oracle Database 사이의 물리적 또는 논리적 통신 경로입니다.

Client Socket
↕
Oracle Net
↕
Listener가 연결 설정
↕
Dedicated Server·Dispatcher·Connection Broker

Connection에는 TCP/IP Socket, Oracle Net Protocol, Listener 주소, Service Handler, Connection Pool의 Physical Connection 등이 관여할 수 있습니다.

1.2 Session

Session은 사용자가 인증된 뒤 Database 안에 만들어지는 논리 작업 상태입니다.

Session에는 다음 상태가 포함될 수 있습니다.

• Database User·Schema
• Transaction 상태와 Lock
• NLS·Optimizer Session Parameter
• Current Schema
• PL/SQL Package State
• Application Context·Client Identifier
• Open Cursor·Temporary LOB
• Global Temporary Table의 Session 상태

Connection = 통신 통로
Session    = Database 안의 로그인·업무 상태

Dedicated Server에서는 하나의 Client Connection과 하나의 Session·Server Process가 1:1처럼 보이는 경우가 많지만 개념적으로 동일하지 않습니다. Connection Pool·Proxy Session·Shared Server·DRCP에서는 Connection과 Session·Server Process의 대응 관계가 달라집니다.

1.3 Database Call

Database Call은 Client가 Database에 보내는 하나의 API 요청 단위입니다.

대표적인 Call은 다음과 같습니다.

• Parse
• Execute
• Fetch
• Commit·Rollback
• Cursor Close

Shared Server에서는 같은 Session의 Parse, 첫 Fetch, 다음 Fetch, Close를 서로 다른 Shared Server Process가 처리할 수 있습니다. 따라서 Session과 현재 Call을 처리하는 Process를 같은 개념으로 보면 안 됩니다.

2. Service·Instance·SID·Net Service Name

2.1 Service

Service는 Application Workload를 나타내는 논리 이름입니다. V$SERVICES.NAME은 Workload를 설명하는 Service 이름이며 NETWORK_NAME은 Client가 접속에 사용하는 Network 이름입니다.

ORDER_SERVICE
→ 주문 업무용 논리 서비스
→ 한 Instance 또는 여러 Instance에서 제공 가능

RAC에서는 같은 Service를 여러 Instance에서 제공해 Connection Load Balancing, Failover, Planned Maintenance, Service 단위 Resource 관리와 모니터링에 활용할 수 있습니다.

2.2 Instance

Instance는 SGA와 Background Process로 구성된 실행 단위입니다. RAC에서는 여러 Instance가 하나의 Database를 공유할 수 있으므로 Service와 Instance를 같은 이름으로 가정하면 안 됩니다.

2.3 SID와 SERVICE_NAME

• SID: 특정 Instance를 식별하는 데 사용되는 이름
• SERVICE_NAME: Application이 원하는 Workload Service
• Net Service Name: tnsnames.ora 등에서 Connect Descriptor에 붙인 Client 측 별칭

Client는 일반적으로 Instance에 직접 고정하기보다 Service를 통해 접속합니다. SERVICE_NAMES Initialization Parameter는 Deprecated됐으므로 HA 환경에서는 SRVCTL·GDSCTL·DBMS_SERVICE로 Service를 관리하는 것이 권장됩니다.

3. Listener와 Service Handler

Listener는 하나 이상의 Protocol Address에서 최초 Connection 요청을 받고, 요청된 Service에 등록된 Handler를 선택합니다.

Client Connection Request
→ Listener
→ SERVICE_NAME 확인
→ 등록된 Instance·Handler·Load 확인
→ Handler로 Handoff·Redirect 또는 Dedicated Server 생성
→ 이후 Client가 Database와 직접 통신

Service Handler는 다음과 같습니다.

• Dedicated Server Process
• Shared Server Dispatcher
• DRCP Pooled Server Handler

Listener는 접속 설정 이후 일반 SQL의 Parse·Optimizer·Block Read·DML·Commit·Fetch를 수행하지 않습니다. 이 작업은 Server Process가 수행합니다.

3.1 Listener가 수행하는 일

• Listening Endpoint에서 접속 요청 수신
• Connect Descriptor의 Service·Protocol 요구 확인
• 등록된 Service와 Handler 상태 조회
• Connection Load Balancing 정보 활용
• Handler로 Connection을 인계하거나 Handler 주소를 Client에 반환

3.2 Listener가 수행하지 않는 일

• SQL Parsing과 실행계획 생성
• Buffer Cache·Datafile Block 접근
• DML과 Transaction 처리
• Result Row 생성과 Fetch

접속 후 SQL이 느린 경우 Listener만 조사해서는 원인을 찾을 수 없습니다. 반대로 Session 생성 전 접속 오류는 SQL 실행계획보다 Listener·Service Registration·Handler 상태를 먼저 확인합니다.

4. LREG와 Dynamic Service Registration

LREG는 Database가 제공하는 Service와 Handler 정보를 Listener에 등록합니다.

Service 이름
+ Instance 이름·현재/최대 Load
+ Dedicated·Dispatcher Handler 주소와 상태
→ LREG
→ LOCAL_LISTENER·REMOTE_LISTENER 대상 Listener

Dynamic Registration은 일반적으로 listener.ora에 Service를 정적으로 나열하지 않아도 됩니다. Listener가 Instance보다 늦게 시작된 경우 LREG의 다음 Discovery까지 등록이 지연될 수 있으며 기본 Discovery 간격은 최대 약 60초입니다.

즉시 등록을 요청할 때는 다음 문장을 사용합니다.

ALTER SYSTEM REGISTER;

이 문장은 Listener가 내려가 있거나 이미 모두 정상 등록된 경우에는 문제를 해결하지 않습니다. LOCAL_LISTENER, REMOTE_LISTENER, Listener Endpoint, Service Open 상태를 함께 확인해야 합니다.

확인 명령

lsnrctl status
lsnrctl services

lsnrctl services에서는 Service·Instance·Handler, Established·Refused Connection, Handler 상태를 확인합니다.

SELECT name,
       network_name,
       goal,
       aq_ha_notification
FROM   v$services
ORDER BY name;

5. Dedicated Server

Dedicated Server에서는 Client Connection마다 전담 Server Process가 연결됩니다.

Client A ─ Dedicated Server A ─ Session A
Client B ─ Dedicated Server B ─ Session B

특징

• 요청 경로가 단순하고 Session·Process 추적이 쉽습니다.
• 긴 Batch·Reporting SQL, 큰 PGA Workarea, 관리 작업에 적합합니다.
• Connection 수가 늘면 Server Process와 PGA 사용량도 대체로 증가합니다.
• Dedicated Session의 UGA는 Server Process의 PGA에 위치합니다.

접속 설정

Connect Descriptor에 다음을 지정하면 Dedicated Handler를 요청할 수 있습니다.

(SERVER=DEDICATED)

Dedicated Server는 Session별 자원 격리가 명확하지만 많은 Idle Connection을 그대로 유지하면 Process·PGA·OS Scheduling 비용이 커질 수 있습니다. 따라서 Middle Tier에서는 일반적으로 Application Connection Pool과 함께 사용합니다.

6. Shared Server

Shared Server는 많은 Client Connection이 적은 Shared Server Process Pool을 나눠 사용하도록 합니다.

Client
→ Dispatcher
→ Virtual Circuit
→ SGA의 Common Request Queue
→ 사용 가능한 Shared Server Process
→ Dispatcher별 Response Queue
→ Dispatcher
→ Client

6.1 구성 요소

Shared Server의 Request·Response Queue는 Large Pool을 사용하도록 구성할 수 있으며, 한 Session의 다음 Database Call은 다른 Shared Server가 처리할 수 있습니다. UGA가 SGA에 있어야 하는 이유가 여기에 있습니다.

6.2 접속 선택 규칙

(SERVER=SHARED)

을 명시했는데 사용할 Dispatcher가 없으면 접속 요청은 거부됩니다. Shared Server가 구성돼 있어도 Client가 Handler 유형을 강제하지 않았고 Dispatcher가 없으면 Dedicated Server로 처리될 수 있습니다.

6.3 적합성과 주의점

적합한 경우:

• Connection 수가 매우 많고 각 Call이 짧음
• Idle 시간이 길고 동시 Active Call 비율이 낮음
• Session당 전담 Process 비용을 줄여야 함

주의할 경우:

• 긴 Batch·Reporting Call
• 큰 Sort·Hash Workarea
• Shared Server 한 개를 오래 점유하는 SQL
• Dispatcher·Common Queue 대기 증가
• Dedicated Connection이 필요한 관리 작업

Shared Server는 Connection Pool이 아닙니다. Client Connection과 Session은 유지하면서 Database Call을 처리하는 Server Process를 공유합니다.

7. Database Resident Connection Pooling

DRCP는 Database Server 측에서 Connection Broker와 Pooled Server를 운영하는 Pool입니다.

Client Connection
→ Connection Broker
→ 사용 가능한 Pooled Server·Session 할당
→ Database Call 수행
→ Pooled Server를 Server 측 Pool에 반환

Connect Descriptor에는 다음 Handler 유형을 지정합니다.

(SERVER=POOLED)

DRCP가 활성화되지 않았는데 SERVER=POOLED를 요청하면 접속은 거부됩니다.

7.1 Shared Server와 차이

DRCP는 Open Connection 수보다 실제 Active Connection 수가 훨씬 적고, 여러 Middle Tier가 각자 많은 Idle Physical Connection을 유지하는 환경에서 Database Process·Memory 낭비를 줄일 수 있습니다.

7.2 Oracle 26ai Multi-Pool DRCP

Oracle 26ai는 여러 Named DRCP Pool을 지원합니다. 특정 Application·Service가 하나의 공용 Pool을 독점해 다른 Workload가 대기하는 상황을 줄이고, Workload별 Pooled Server Capacity를 분리할 수 있습니다.

DRCP에서도 Connection Class·Purity·Tag와 Session State 정책을 일관되게 설계해야 합니다. 이전 Session State를 사용할 수 없는 요청은 깨끗한 Session을 요구해야 합니다.

8. Application Connection Pool

Application Connection Pool은 Middle Tier에서 미리 생성한 Physical Database Connection을 보관하고 요청마다 Logical Connection을 빌려줍니다.

Application Request
→ Pool에서 Logical Connection 대여
→ 기존 Physical Connection·Session 사용
→ SQL 실행
→ Logical Connection close()
→ Physical Connection을 Pool에 반환

Pool 환경에서 close()는 Network Socket과 Database Session 종료가 아니라 사용권 반환인 경우가 많습니다.

8.1 Pool이 줄이는 비용

• TCP Connection 설정
• Listener 접속과 Handler 연결
• Authentication
• Session 생성
• 초기 Session 설정
• Dedicated Server Process 또는 Pooled Resource 준비

8.2 Bulkhead 역할

Connection Pool은 Cache이면서 동시에 Database로 들어가는 Active Call 수를 제한하는 Bulkhead입니다.

Application Thread 300개
→ Pool 30개
→ 최대 30개 Database 작업
→ 나머지는 Pool Queue 대기

Pool Size를 Thread 수와 같게 키우면 Pool Wait는 줄어도 DB CPU·I/O Queue·Latch·Lock 경합이 증가해 전체 응답시간과 처리량이 악화될 수 있습니다.

9. Logical Close와 Session State Reset

Physical Connection과 Session을 재사용하면 이전 요청의 상태가 다음 요청에 노출될 수 있습니다.

9.1 반드시 정리할 항목

• 미완료 Transaction과 Row Lock
• Auto-Commit·Isolation 설정
• NLS·Optimizer Session Parameter
• Current Schema
• PL/SQL Package State
• Application Context·Client Identifier
• Temporary Table·Temporary LOB
• Open ResultSet·Statement·Cursor

9.2 반환 원칙

성공
→ 업무 단위 COMMIT
→ ResultSet·Statement Close
→ Session State 복구
→ Pool 반환

실패
→ ROLLBACK
→ Resource Close
→ Connection 유효성 확인
→ Pool 반환 또는 폐기

Pool이 자동 Commit을 해줄 것이라고 가정하면 Transaction 경계가 숨겨지고 부분 변경이 Commit될 수 있습니다. 업무 코드가 Commit·Rollback을 명시해야 합니다.

9.3 Oracle 26ai RESET_STATE

RESET_STATE Service Attribute는 명시적인 Request Boundary가 끝날 때 Application이 남긴 Session State를 정리해 이후 사용으로 상태가 누출되는 것을 줄입니다. Oracle 26ai에서는 Application Continuity와 독립적으로 사용할 수 있습니다.

RESET_STATE LEVEL1은 Cursor 취소, PL/SQL Global State, Session Duration Temporary Table·LOB 등 복잡한 Session State를 정리할 수 있습니다. 그러나 이는 업무 Transaction의 성공 여부를 대신 판단하지 않으므로 명시적 Commit·Rollback과 Resource Close 책임은 그대로 남습니다.

10. Pool Size와 Capacity 진단

10.1 Application 측 지표

• Active·Idle Connection
• Borrow Wait Time과 Timeout
• Connection Hold Time
• Request Queue 길이
• 생성·폐기 Connection 수
• 실패와 재시도 수

10.2 Database 측 지표

• Service별 Active Session
• DB CPU·Average Active Sessions
• I/O Latency·Queue
• Lock·Latch·Library Cache 대기
• Process·Session·PGA 사용량
• processes, sessions 한도
• Shared Server Request Queue

10.3 판단 예시

Pool 20
→ 일부 Pool Wait
→ DB CPU 70%
→ 안정적인 처리량

Pool 100
→ Pool Wait 감소
→ DB CPU 100%
→ I/O·Lock 증가
→ p95 응답시간 악화

가장 큰 Pool이 아니라 목표 처리량과 응답시간을 안정적으로 유지하는 최소 동시성을 선택합니다. Pool Wait가 있다는 사실만으로 Pool Size 부족을 결론내지 않고 긴 Transaction·Connection Leak·느린 SQL을 먼저 분리합니다.

11. Runtime 진단

11.1 Session과 Process

SELECT s.sid,
       s.serial#,
       s.username,
       s.status,
       s.server,
       s.service_name,
       s.machine,
       s.program,
       s.module,
       s.client_identifier,
       p.spid
FROM   v$session s
LEFT JOIN v$process p
  ON   p.addr = s.paddr
WHERE  s.type = 'USER'
ORDER BY s.status DESC, s.sid;

V$SESSION.PADDR = V$PROCESS.ADDR는 현재 Session과 Process를 연결합니다. Shared Server에서는 현재 Call을 처리하지 않는 시점의 Process 연결을 Dedicated Session처럼 고정 관계로 해석하지 않습니다.

11.2 Service별 Session

SELECT service_name,
       status,
       server,
       COUNT(*) AS session_count
FROM   v$session
WHERE  type = 'USER'
GROUP BY service_name, status, server
ORDER BY service_name, status, server;

11.3 Shared Server

SELECT name, status, requests, messages, bytes
FROM   v$dispatcher
ORDER BY name;

SELECT name, status, requests, messages
FROM   v$shared_server
ORDER BY name;

SELECT circuit, dispatcher, server, saddr, status, queue
FROM   v$circuit;

• V$DISPATCHER: Dispatcher 상태와 처리 통계
• V$SHARED_SERVER: Shared Server 상태
• V$CIRCUIT: Virtual Circuit과 현재 Queue·Process 연결
• V$QUEUE: Common·Dispatcher Queue 대기
• V$SHARED_SERVER_MONITOR: Shared Server Capacity 통계

11.4 Resource 한도

SELECT resource_name,
       current_utilization,
       max_utilization,
       limit_value
FROM   v$resource_limit
WHERE  resource_name IN ('processes', 'sessions');

누적 최대값만 보지 말고 접속 장애 구간의 Listener Handler 상태, Active Session, Process 한도, Pool 대기를 같은 시간축으로 비교합니다.

12. 접속 오류 진단 순서

1. Host·Port의 Listener에 도달하는가?
2. 요청 SERVICE_NAME이 Listener에 등록돼 있는가?
3. 해당 Service에 원하는 Handler가 등록·Ready 상태인가?
4. Database·PDB와 Service가 실제로 Open·Started 상태인가?
5. Process·Session·Shared Server·DRCP Pool 한도가 충분한가?
6. 인증 후 Session이 생성되는가?
7. Pool Borrow와 Connection Validation에서 지연되는가?
8. SQL 실행 이후의 Database 대기인가?

대표 증상

ORA-12514는 Service가 Listener에 등록되지 않은 문제이고, ORA-12516은 등록된 Service에 Client 요구와 맞는 Ready Handler가 없는 문제입니다. 두 오류를 같은 방식으로 처리하면 안 됩니다.

13. 혼동하기 쉬운 판단

14. 진단·적용 절차

1. 업무 Service와 Handler 유형을 정의한다.
2. lsnrctl services로 등록된 Service·Handler를 확인한다.
3. Dedicated·Shared·DRCP 중 Connection 특성에 맞는 구조를 선택한다.
4. Application Pool의 최소·최대 크기와 대기 정책을 설정한다.
5. Transaction·Session State Reset Contract를 정한다.
6. 실제 부하에서 Pool Wait·Active Session·DB CPU·Queue를 함께 측정한다.
7. 접속 실패와 SQL 실행 지연을 시간축으로 분리한다.
8. 변경 후 처리량·p95 응답시간·오류율·Process·Memory를 재검증한다.