서버 프로세스 (by hun1361) [2012.10.12]
서버 프로세스
서버 프로세스란?
클라이언트 세션에서 데이타 베이스로 보내는 SQL 문을 받아서 처리하는 프로세스
서버 프로세스는 정렬 , 합계 , 조인등의 작업을 수행할때 시스템의 CPU 시간을 가장 많이 소비함
Dedicated Server vs Shared Server vs DRCP
1) Dedicate Server :
- 클라이언트 커넥션과 서버 프로세스는 일대일 관계다.
- 가장 흔한 방법이며 설치하기 간단하다.
- 장시간 수행하는 배치환경에서 사용할수 있는 유일한 모드이다.
- 오라클에서 추천하는 구성이며 확장도 용이하다
!dedicated server connection.jpg!
p223.그림5-1
--부모/자식 프로세스 생성 과정
select a.spid dedicated_server,
b.process clientpid
from v$process a, v$session b
where a.addr = b.paddr
and b.sid = (select sid from v$mystat where rownum=1)
/
DEDICATED_SE CLIENTPID
------------ ------------
1700538 1630904
sys@BWD> !ps -fp 1700538,1630904
UID PID PPID C STIME TTY TIME CMD
orabwd 1630904 1417636 0 20:47:58 pts/5 0:00 sqlplus
orabwd 1700538 1630904 0 20:47:58 - 0:00 oracleBWD (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
--1700538 프로세스가 1630904프로세스의 자식
--1630904 프로세스가 sqlplus프로세스의 자식
2) Shared Server 커넥션
- 리스너를 사용해야 shared server를 사용할 수 있다.
- 다대일 관계가 존재한다. (다수의 클라이언트 대 한개의 shared server)
- 인위적인 데드락(하나의 shared server에 여러사용자가 붙어서 사용하므로 shared server독점으로인한 데드락 발생)
- 장시간 동안 shared server 를 독점하지 않도록 주의가 필요하다.
- 트랜잭션 수행시간이 짧고 자주 수행되는 특징을 가진 OLTP 시스템에서만 적합하다.
- 잠재적인 이점
- 운영체제 프로세스 / 쓰레드 줄이기
- 인위적으로 동시성 정도 제한하기
p236.그림5-3 - 시스템에 필요한 메모리량 줄이기
5000개의 dedicated server -> 100개 shared server (4900PGA메모리절약)
최근버전에는 자동으로 메모리가 회수되고 할당되므로 의미를 두지 않음:자동PGA메모리관리)
!shared server connection.jpg!
p225.그림5-2
- 클라이언트 애플리케이션은 물리적으로 dispatcher 프로세스와 연결되어 있음을 볼수 있다.
- dispatcher 는 단순히 클라이언트의 요청을 받아서 SGA 의 request queue 에 넣는 역활을 한다. 미리 생성된
shared server 프로세스 중에서 첫번째로 가용한 shared server 프로세스는 큐로 부터 요청을 꺼내어 관련된
세션의 UGA 에 집어 넣고 그 요청을 처리한 다음 결과를 response queue 에 넣는다. dispatcher 는 항상
response queue 를 감시하닥 해당 요청에 대한 결과를 찾으면 클라이언트 애플리케이션으로 돌려준다. - 클라이언트 입장에서는 dedicated 인지 shared 인지 구분할수 없으며 동일하게 보인다. 데이타 베이스 수준에서
만 뚜렷한 차이점을 보인다.
3) 데이타 베이스 상주 커넥션 풀링 (DRCP)
- 11g 새로운 기능
- 데이터 베이스에 연결하여 세션을 만드는 새로운 방법이며 선택사항이다.
- dedicated server 와 shared server 를 섞어 놓은 개념이다.
- 서버 프로세스를 풀링하는 개념은 shared server 방식과 동일하지만 풀을 구성하는 서버 프로세스는 shared server 가 아니라 dedicated server 만 가능하다.
- 한세션에서 세가지 서로다른 sql문을 실행시킬때
shared server: 세개의 서로다른 shared server 프로세스가 각 SQL문을 실행한다.
DRCP : 풀에서 세션에 할당된 dedicated server가 세개의 SQL문을 모두 수행한다.
커넥션대 세션
- 커넥션 과 세션은 동의어가 아니다.
- 한개의 커넥션은 세션이 없을수도 있고 한개 이상의 세션이 있을수도 있다.
- 커넥션은 단순히 클라이언트 프로세스와 데이터베이스 인스턴스간의 물리적인 경로(대개 네트워크 커넥션)만 제공한다.
- 커넥션은 네트워크를 통해서 또는 IPC(InterProcess Commuication:프로세스간통신) 메커니즘을 통해서 설정될수 있다.
- 커넥션은 일반적으로 클라이언트 프로세스와 dedicated server 또는 dispatcher 간의 연결이다.
- 세션은 인스턴스에 존재하는 논리적인 개체며 세션의 상태와 사용자의 세션을 유일하게 표현하는 메모리상에 존재하는 자료구조의 묶음이다.
- 사용자는 서버에 존재하는 세션에서 SQL 을 실행하고 트랜잭션을 커밋하고 저장프로시저를 실행한다.
-- dedicated 서버에서 한개의 커넥션이 하나 이상의 세션을 갖는 예
scott@BWD> set echo on
scott@BWD> column username format a9
scott@BWD>select username, sid, serial#, server, paddr, status
from v$session
where username = USER
/
USERNAME SID SERIAL# SERVER PADDR STATUS
--------- ---------- ---------- --------- ---------------- --------
SCOTT 575 47 DEDICATED 070000001F67A068 ACTIVE
sys@BWD> set autotrace on statistics
select username, sid, serial#, server, paddr, status
from v$session
where username = USER
/
USERNAME SID SERIAL# SERVER PADDR STATUS
--------- ---------- ---------- --------- ---------------- --------
SCOTT 575 47 DEDICATED 070000001F67A068 ACTIVE --둘다 같은 dedicated server프로세스 주소를사용(한 커넥션만사용)
SCOTT 589 35 DEDICATED 070000001F67A068 INACTIVE --AUTOTRACE세션(세션을 지켜보다가 무엇을하는지 보고하는일수행)
Statistics
----------------------------------------------------------
8 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
936 bytes sent via SQL*Net to client
488 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
2 rows processed
set autotrace off
--※SQL*Plus에서 AUTOTRACE 기능을 활성화할 때 SQL*Plus는 사용자가 DML작업을 실행할 때 다음과 같은 단계를 수행
--1. 현재 커넥션을 이용하여 두번째 세션이 존재하지 않는다면 새로운 세션을 생성
--2. DML을 실행하는 세션의 초기 통계값을 기억하기 위해 SQL*Plus는 이 보조세션에 V$SESSTAT뷰를 조회하도록 요청.
--3. SQL*Plus는 원래 세션에서 DML작업실행.
--4. DML문이 완료되면 SQL*Plus는 두 번째 세션에 다시 V$SESSTAT를 조회하도록 요청하고, DML을 수행한 세션에 대하여 이전과 다르게 나타난 수치를 보여주는 리포트를 생성.
scott@BWD> disconnect(물리적인 커넥션 끊는명령어는 아님, DESTROY_ALL_SESSIONS명령어가 끊는명령어)
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
--새로운세션
SYS@BWD> select username, sid, serial#, server, paddr, status
from v$session
where username = 'SCOTT';
no rows selected
--세션이 존재하지 않지만 여전히 물리적인 커넥션을 가진 프로세스를 갖고있다.
sys@BWD> select username, program
2 from v$process
3 where addr = hextoraw('070000001F67A068');
USERNAME PROGRAM
--------------- ------------------------------------------------
orabwd oracle@r3dev (TNS V1-V3)
--처음세션
scott@BWD> connect scott/tiger
Connected.
scott@BWD> select username, sid,serial#,server,paddr,status
2 from v$session
3 where username = 'SCOTT';
USERNAME SID SERIAL# SERVER PADDR STATUS
--------- ---------- ---------- --------- ---------------- --------
SCOTT 589 43 DEDICATED 070000001F67A068 ACTIVE --이전과 동일한PADDR
--같은 물리적 커넥션을 사용하고있지만 다른 SID를 갖고있다.
h3. shared server를 사용해서 로그인
{code:sql}
scott@BWD> select a.username, a.sid, a.serial#, a.server,
a.paddr, a.status, b.program
from v$session a left join v$process b
on (a.paddr = b.addr)
where a.username = 'SCOTT';
USERNAME SID SERIAL# SERVER PADDR STATUS PROGRAM
------------------------------ ----------- ----------- --------- ---------------- -------- ------------------------------------------------
SCOTT 577 20 SHARED 070000001F67B028 ACTIVE oracle@r3dev (S000)
1 rows selected.
--프로세스가 shared server라는것을 문자열 S000을 통해 알 수 있다.
--다른세션
SYS@BWD> select a.username, a.sid, a.serial#, a.server,
a.paddr, a.status, b.program
from v$session a left join v$process b
on (a.paddr = b.addr)
where a.username = 'SCOTT';
USERNAME SID SERIAL# SERVER PADDR STATUS PROGRAM
------------------------------ ----------- ----------- --------- ---------------- -------- ------------------------------------------------
SCOTT 577 20 NONE 070000001F67A848 INACTIVE oracle@r3dev (D001)
1 rows selected.
--PADDR,프로세스 이름 바뀜.
--idle상태인 처음 세션은 이제 dispatcher D000와 관련되어 있다.
--단일 프로세스를 가리키는 다수의 세션을 관찰하기위한 다른방법은 없다.(dispatcher는 자신을 가리키는 수백,수천개의 세션을 가질 수 있기 때문)
--처음세션에서 위쿼리를 반복해서 실행을하면 계속 같은 PADDR을 조회 할 수 있다. 그러나 좀 더 많은 shared server 커넥션을 열어놓고 다른세션에서
shared server 커넥션을 사용하도록 하면, shared server가 변한다는 것을 발견할 수 있다.
--<세션1>
scott@BWD> select a.username, a.sid, a.serial#, a.server,
2 a.paddr, a.status, b.program
3 from v$session a left join v$process b
4 on (a.paddr = b.addr)
5 where a.username = 'SCOTT'
6 /
USERNAME SID SERIAL# SERVER PADDR STATUS PROGRAM
---------- ---------- ---------- --------- ---------------- -------- ------------------------------
SCOTT 576 35 SHARED 070000001F67B028 ACTIVE oracle@r3dev (S000)
--<세션2>
sqlplus scott/tiger@bwd
exec dbms_lock.sleep(20);
--<세션1>
--dbms_lock.sleep 이 실행되는 동안 shared server는 S001로 변경됨
scott@BWD> /
USERNAME SID SERIAL# SERVER PADDR STATUS PROGRAM
---------- ---------- ---------- --------- ---------------- -------- ------------------------------
SCOTT 576 37 SHARED 070000001F67B808 ACTIVE oracle@r3dev (S001)
--세션2가 완료됐을때 shared server는 다시 S000을 사용
scott@BWD> /
USERNAME SID SERIAL# SERVER PADDR STATUS PROGRAM
---------- ---------- ---------- --------- ---------------- -------- ------------------------------
SCOTT 576 37 SHARED 070000001F67B028 ACTIVE oracle@r3dev (S000)
-- 처음 쿼리시 shared server 는 S000
-- 다른 세션에서 긴작업 ( 이때 S000 을 할당받음)
-- 첫번째 세션에서 다시 쿼리를 날릴시 S001 로 할당 받음