공유 서버와 디스패처

#핵심 요약

전용 서버는 서버 프로세스 하나가 클라이언트 하나를 전담함
단순하지만 접속이 몰리면 프로세스마다 쓰는 CPU와 메모리가 커져 확장성이 떨어짐

공유 서버는 여러 클라이언트가 적은 수의 공유 서버 프로세스를 나누어 씀
디스패처가 요청을 받아 SGA의 공통 요청 큐에 넣고, 공유 서버 프로세스가 꺼내 처리함

요청 큐는 인스턴스에 하나, 응답 큐는 디스패처마다 하나임
응답은 요청을 보낸 그 연결로만 돌아감

인스턴스 설정은 DISPATCHERS 파라미터로, 세션별 방식은 V$SESSION.SERVER로 확인함

#개념과 동작 원리

#접속 흐름

1. 공유 서버에 참여하는 서비스는 디스패처를 하나 이상 가짐
2. 리스너는 접속 요청이 오면 전용 서버 프로세스를 만드는 대신, 그 서비스의 디스패처 중 현재 접속 수가 가장 적은 쪽으로 보냄
3. 한 번 연결된 디스패처는 세션이 끝날 때까지 바뀌지 않음
4. 디스패처는 요청을 SGA 공유 풀에 있는 공통 요청 큐에 넣기만 함
   디스패처 하나가 수백 개 접속을 맡을 수 있음
5. 손이 빈 공유 서버 프로세스가 공통 요청 큐에서 요청을 꺼내 처리함
6. 결과는 그 요청을 보낸 디스패처의 응답 큐에 들어가고, 디스패처가 원래 연결로 돌려보냄

실습의 비유: 카운터 직원(디스패처)이 주문을 받아 대기열(공통 요청 큐)에 넣으면 주방 요리사(공유 서버 프로세스)가 순서대로 처리함

설명: 요청은 아무 공유 서버가 처리해도 되므로 한곳에 모으고, 응답은 반드시 보낸 사람에게 가야 하므로 디스패처별로 나눔
"공통 응답 큐", "공유 서버별 입력 큐", "모든 연결에 응답 브로드캐스트"는 이 구조와 맞지 않음

#필수 명령어 또는 SQL

#전용 서버에서 세션과 OS 프로세스 확인

ps -ef | grep "oracle<SID>" | grep -v grep

SELECT s.sid, s.username, s.server, p.spid, p.pga_alloc_mem/1024/1024 "PGA(MB)"
  FROM v$session s, v$process p
 WHERE s.paddr = p.addr
   AND s.username = '<USERNAME>';

결과 해석:

실습 기록: 원격 접속 하나마다 oracle<SID> (LOCAL=NO) 프로세스가 하나씩 보였고, V$SESSION.SERVER는 DEDICATED, SPID가 운영체제 프로세스 번호와 같았음

#현재 설정 확인

SHOW PARAMETER dispatchers
SHOW PARAMETER shared_servers
SELECT name, status, requests, messages FROM v$shared_server;

결과 해석:

실습 기록: 기본 상태에서 DISPATCHERS는 (PROTOCOL=TCP) (SERVICE=<SID>XDB), SHARED_SERVERS는 1, V$SHARED_SERVER에는 S000(WAIT(COMMON)) 하나가 있었음
실습에서는 DISPATCHERS 값이 비어 있으면 공유 서버가 꺼져 있고 모든 접속이 전용 서버라고 적었음

#공유 서버 켜기

ALTER SYSTEM SET dispatchers =
  '(PROTOCOL=TCP)(SERVICE=<SID>XDB)',
  '(PROTOCOL=TCP)(DISPATCHERS=2)(SERVICE=<SERVICE_NAME>)'
  SCOPE = BOTH;

ALTER SYSTEM SET shared_servers = 2 SCOPE = BOTH;

SELECT name, network, status, accept, owned FROM v$dispatcher;
SELECT name, status, requests, messages FROM v$shared_server;

결과 해석:

실습 기록: V$DISPATCHER에 D000, D001이 WAIT, ACCEPT=YES로 나왔음
실습의 첫 실습은 XDB 항목 없이 서비스 하나만 지정해 기존 XDB 디스패처 설정을 덮어썼고, 다음 실습에서 위처럼 XDB 항목을 살린 채 추가했음

lsnrctl services

결과 해석:

실습 기록: 공유 서버를 설정한 서비스에는 DEDICATED 처리기와 함께 디스패처 D000, D001이 처리기로 보였음
디스패처를 설정하기만 한 직후 lsnrctl status에는 달라진 것이 없었음

#공유 서버와 전용 서버로 골라 접속

sqlplus <USERNAME>@<HOST>:1521/<SERVICE_NAME>:shared
sqlplus <USERNAME>@<HOST>:1521/<SERVICE_NAME>:dedicated

SELECT sid, server FROM v$session WHERE sid = SYS_CONTEXT('USERENV', 'SID');

결과 해석:

실습 기록: Easy Connect 끝에 :shared를 붙이면 SERVER가 SHARED, :dedicated를 붙이면 DEDICATED였음
SYS에서 사용자 세션을 모아 보자 공유 서버 세션 일부는 SERVER가 NONE으로 나왔음
그 순간 공유 서버 프로세스가 붙어 있지 않은 상태로 보이나 설명은 기재 없음

#원래대로 되돌리기

ALTER SYSTEM SET dispatchers = '(PROTOCOL=TCP)(SERVICE=<SID>XDB)' SCOPE = BOTH;
ALTER SYSTEM SET shared_servers = 1 SCOPE = BOTH;

결과 해석: 개별 실행 출력은 기재 없음

#사용 조건과 주의사항

실습에서는 SHARED_SERVERS 값 1을 "orclXDB용 디스패처"라고 주석을 달았음
SHARED_SERVERS는 공유 서버 프로세스 수이고 디스패처는 DISPATCHERS로 정하므로 주석 설명이 맞지 않음

Oracle Database 19c에서 SHARED_SERVERS는 기동할 공유 서버 수이자 부하 감소 시 유지할 최소 수를 지정함
DISPATCHERS는 디스패처 프로세스를 구성하므로 두 파라미터는 같은 대상이 아님
DISPATCHERS는 PDB에서 변경할 수 없으며 SHARED_SERVERS의 PDB 설정은 0으로 사용을 끄거나 RESET으로 다시 허용하는 용도로 제한됨

DISPATCHERS를 값 하나로 바꾸면 기존 항목(XDB 디스패처 포함)을 덮어씀
EM Express는 XDB 디스패처를 씀(SQL Developer와 관리 화면)