Search Results for 'Dedicated Server'

1 POSTS

  1. 2012|05 Oracle - 서버 프로세스 : Dedicated Server, Shared Server, DRCP



# 서버 프로세스

서버 프로세스는 클라이언트 세션을 대신하여 일을 수행하는 프로세스다.
즉, 클라이언트 세션에서 데이터베이스로 보내는 SQL 문을 받아서 처리하는 프로세스다.

    * Dedicated server : 서버에는 클라이언트 커넥션별로 dedicated server가 존재하는데, 데이터베이스에 대한 커넥션과 서버 프로세스는 일대일 매핑 관계를 갖는다.
    * Shared server : 오라클 인스턴스는 많은 세션이 함께 공유할 수 있는 서버 프로세스 풀을 관리한다.
    클라이언트 커넥션은 dedicated server 대신 서버 프로세스 풀에 있는 서버 프로세스와 중개 역할을 담당하는 데이터베이스 dispatcher로 작업을 요청한다.

- Note --------------------------------------------------------------------------
오라클 용어로 커넥션과 세션의 차이를 이해하는 것은 중요하다.
커넥션(connection)은 클라이언트 프로세스와 오라클 인스턴스 간의 물리적 경로일 뿐이다(예:사용자와 인스턴스 간의 네트워크 커넥션).
다른 한편으로 세션(session)은 클라이언트 프로세스가 SQL을 실행할 수 있는, 데이터베이스에 존재하는 논리적인 개체(entity)다.
다수의 독립적인 세션이 단 한 개의 커넥션과 관련을 가질 수도 있고, 커넥션으로부터 독립적으로 존재할 수도 있다.
---------------------------------------------------------------------------------

dedicated server 프로세스와 shared server 프로세스 둘 다 사용자가 입력한 SQL을 처리한다.
데이터베이스로 SELECT * FROM EMP 쿼리를 보내면 오라클 dedicated / shared 서버 프로세스는 그 쿼리를 파싱(parsing)하고 shared pool에 배치한다(또는 shared pool에 동일한 쿼리가 존재하는지 검색한다).
두 프로세스 모두 실행계획을 세우고 실행하며, 버퍼 캐시에서 필요한 데이터를 찾거나 디스크에서 데이터를 읽어서 버퍼 캐시로 옮긴다.

서버 프로세스는 정렬(sorting), 합계(summing), 조인(joining) 등의 작업을 수행할 때 시스템의 CPU 시간을 가장 많이 소비한다.



# Dedicated Server 커넥션

dedicated server 모드에서는 클라이언트 커넥션과 서버 프로세스(또는 경우에 따라 쓰레드) 간에 일대일 매핑 관계가 성립한다.
즉, 유닉스 장비에서 dedicated server 커넥션이 100개 존재한다면 이 커넥션들을 위하여 실행하는 프로세스가 100개 존재한다.

그림 5-1 | 일반적인 dedicated server

클라이언트 애플리케이션은 오라클 라이브러리를 링크한다.
오라클 라이브러리는 데이터베이스와 인터페이스 하기 위한 API를 제공한다.
API는 쿼리를 데이터베이스로 보내는 방법, 러턴된 커서(cursor)를 처리하는 방법을 알고 있다.
또한 API는 요청을 네트워크 호출로 변환하는 방법을 알고 있다(dedicated server는 반대로 네트워크 호출로부터 요청을 변환하는 방법을 알고 있다).
이런 소프트웨어를 Oracle Net(이전 릴리즈에서는 SQL*Net 똔느 Net8으로 알려져 있다)이라 부른다.
Oracle Net은 오라클이 클라이언트/서버 처리를 하기 위해 사용하는 네트워킹 소프트웨어/프로토콜이다(n-tier 아키텍처에서도 클라이언트/서버 프로그램이 존재하지만, 단지 보이지 않을 뿐이다).
클라이언트와 서버가 같은 장비에 존재하더라도 이 두 프로세스(또는 두 개의 테스크로 알려진) 아키텍처는 여전히 사용되고 있다.
이 아키텍처는 두 가지 이점을 제공한다.
    * 원격 실행 : 클라이언트 애플리케이션이 데이터베이스 서버와 다른 장비에서 실행하는 것은 당연하다.
    * 주소 공간 고립 : 서버 프로세스는 SGA에 읽기-쓰기 권한을 갖고 있다.
    클라이언트 프로세스와 서버 프로세스가 물리적으로 함께 링크되어 있다면, 클라이언트 프로세스의 잘못된 포인터가 SGA에 있는 자료구조를 쉽게 망가뜨릴 수 있다.

동일한 장비에서 클라이언트와 서버를 실행해보면 유닉스에서는 부모/자식 프로세스 생성 과정을 명확하게 볼 수 있다.

SQL> select a.spid dedicated_server, b.process clientpid
  2  from v$process a, v$session b
  3  where a.addr = b.paddr
  4  and b.sid = (select sid from v$mystat where rownum=1)
  5  /

DEDICATED_SERVER         CLIENTPID
------------------------ ------------------------
29772                    29761

SQL> !/bin/ps -fp 29772 29761
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
oracle   29761 13342  0 14:17 pts/2    S+     0:00 sqlplus       
oracle   29772 29761  0 14:17 ?        Ss     0:00 oracleora11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

SQL> !ps -ef | grep oracle
oracle   29761 13342  0 14:17 pts/2    00:00:00 sqlplus       
oracle   29772 29761  0 14:17 ?        00:00:00 oracleora11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))


여기서 dedicated server와 관련된 프로세스 ID(PID)를 보기 위해 쿼리를 사용했다(위 쿼리를 실행하는 동안 사용되고 있는 프로세스의 운영체제 PID가 바로 V$PROCESS의 SPID 컬럼이다).
/bin/ps -fp의 결과는 부모 프로세스 ID(PID)를 포함하고 있으며, dedicated server 프로세스(프로세스 ID가 29772)가 SQL*Plus 프로세스(프로세스 ID가 29761)의 자식이라는 것을 보여준다.



# Shared Server 커넥션

이제 shared server 프로세스를 좀 더 자세히 살펴보자.
shared server 커넥션은 클라이언트와 서버가 동일한 장비에 있더라도 Oracle Net을 강제적으로 사용한다(사용자는 Oracle TNS 리스너를 사용해야 shared server를 사용할 수 있다).
앞에서 설명했듯이 클라이언트 애플리케이션은 오라클 TNS 리스너에 연결한 다음, dispatcher로 방향을 바꾸고 요청을 넘겨준다.
dispatcher는 클라이언트 애플리케이션과 shared server 프로세스 간의 파이프처럼 작동한다.

그림 5-1 | 일반적인 shared server 커넥션

오라클 라이브러리를 링크한 클라이언트 애플리케이션은 물리적으로 dispatcher 프로세스와 연결되어 있음을 볼 수 있다.
한 개의 인스턴스에 여러 개의 dispatcher를 둘 수 있지만, 수백(혹은 수천) 명의 사용자를 위해 한 개의 dispatcher만 두는 경우도 종종 있다.
dispatcher는 단순히 클라이언트 애플리케이션이 보낸 요청을 받아서 SGA의 요청 큐(request queue)에 넣는 역할을 수행한다.
미리 생성된 shared server 프로세스 중에서 첫 번째로 가용한 shared server 프로세스는 큐로부터 요청을 꺼내어 관련된 세션의 UGA에 집어 넣고(그림 5-2에서 'S' 박스들), 그 요청을 처리한 다음 결과를 응답 큐(response queue)에 넣는다.
dispatcher는 항상 응답 큐를 감시하고 있다가 해당 요청에 대한 결과를 찾으면 클라이언트 애플리케이션으로 되돌려준다.
클라이언트 입장에서 보면, 자신이 dedicate server로 연결되어 있는지 아니면 shared server 로 연결되어 있는지 구분할 수 없으며 동일하게 보인다.
데이터베이스 수준에서만 뚜렷한 차이점을 보인다.



# 데이터베이스 상주 커넥션 풀링(DRCP)

DRCP(Database Resident Connection Pooling, 데이터베이스 상주 커넥션 풀링)는 데이터베이스에 연결하여 세션을 만드는 새로운 방법이며, 선택사항이다.
자체적으로 커넥션 풀링을 지원하지 않는 애플리케이션 인터페이스(가령, 범용적인 목적의 웹 스크립팅 언어인 PHP)를 위해 설계된 방법이다.
DRCP는 dedicated server와 shared server를 섞어 놓은 개념이다.
서버 프로세스를 풀링하는 개념은 shared server 방식과 동일하지만, 풀을 구성하는 서버 프로세스는 shared server가 아니라 dedicated server만 가능하도록 dedicated server 개념을 차용했다.

shared server 커넥션에서 shared server 프로세스는 다수의 세션이 공유하고, 단일 세션은 다수의 shared server 프로세스를 사용한다.
그러나 DRCP에서는 풀에서 선택된 dedicated server 프로세스는 살아있는 동안에는 클라이언트 프로세스와 일대일 매핑된다.
shared server의 경우, 세션에서 세 가지 SQL 문을 실행하면 세 개의 서로 다른 shared server 프로세스가 각 SQL 문을 수행한다.
DRCP를 사용하는 경우, 풀에서 세션에 할당된 dedicated server가 세 개의 SQL 문을 모두 수행한다.
사용자 세션이 dedicated server를 다시 풀로 보낼 때까지는 사용자 세션만을 위한 전용 서버가 된다.
그래서 DRCP는 shared server의 풀링 기능과 dedicated server의 성능을 갖고 있다.


# 커넥션 대 세션

한 커넥션을 사용하는 각 세션은 서로 다른 사용자 ID를 사용할 수 있다.

    * 커넥션 : 커넥션은 클라이언트가 오라클 인스턴스까지 도달하는 물리적 경로다.
       커넥션은 네트워크를 통해서 IPC 메커니즘을 통해서 설정될 수 있다.
       커넥션은 일반적으로 클라이언트 프로세스와 dedicated server 또는 dispatcher 간의 연결이다.
       그러나 오라클의 Connection Manager(CMAN)을 이용하며 커넥션은 클라이언트와 CMAN 사이 또는 CMAN과 데이터베이스 사이의 연결일 수 있다.
       CMAN을 다루는 것은 이 책의 범위를 넘어서지만 Oracle Net SErver Administrator's Guide에서 좀 더 자세하게 다루고 있다.
   
    * 세션 : 세션은 인스턴스에 존재하는 논리적인 개체며, 세션의 상태와 사용자의 세션을 유일하게 표현하는 메로리 상에 존재하는 자료구조의 묶음이다.
       세션은 사람들이 데이터베이스 커넥션을 생각할 때 제일 먼저 떠올리는 단어다.
       사용자는 서버에 존재하는 세션에서 SQL을 실행하고 트랜잭션(transaction)을 커밋하고, 저장 프로시저를 실행한다.

SQL*Plus를 사용하면 활동 중인 커넥션과 세션을 볼 수 있는데, 한 개의 커넥션이 하나 이상의 세션을 갖는 일은 매우 흔하다.
특히 AUTOTRACE 명령어를 사용하면 사용자와 인터페이스하는 세션 외에 한 개의 추가 세션을 발견할 수 있다.
아래 예제에서는 단일 프로세스를 이용해서 단일 커넥션에 두 개의 세션을 설정할 것이다.
SQL> select username, sid, serial#, server, paddr, status
  2    from v$session
  3    where username = USER
  4  /

USERNAME               SID    SERIAL#    SERVER      PADDR                    STATUS
-------------------- ---------- ---------- --------- ---------------- --------
SUNSHINY                21        462       DEDICATED   00000000D04DDEE0    ACTIVE


지금은 한 개의 세션(한 개의 dedicated server와 연결된 세션)만 보여주고 있다.
PADDR 컬럼은 바로 dedicated server 프로세스의 주소다.
이제 SQL*Plus에서 실행하는 문장의 통계를 보기 위해서 AUTOTRACE 기능을 활성화한다.

SQL> set autotrace on statistics
SQL> select username, sid, serial#, server, paddr, status
  2      from v$session
  3     where username = USER
  4  /

USERNAME               SID    SERIAL# SERVER    PADDR                 STATUS
--------------------- ---------- ---------- --------- ---------------- --------
SUNSHINY                 19        613 DEDICATED 00000000D04DDEE0   INACTIVE
SUNSHINY                 21        462 DEDICATED 00000000D04DDEE0   ACTIVE


Statistics
----------------------------------------------------------
          8  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        997  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          2  rows processed

SQL> set autotrace off

두 개의 세션이 존재하지만, 둘 다 똑같은 PADDR 값을 가진 것으로 보아 같은 dedicated server 프로세스를 사용하고 있다는 것을 알 수 있다.
별도의 프로세스를 생성하지 않고 한 개의 프로세스(두 개의 세션 모두 한 개의 커넥션)만 사용하고 있다는 것을 운영체제에서 확인할 수 있다.
주의할 것은 두 개의 세션 중 하나(원래 세션)는 ACTIVE 상태며, 세션 정보를 보여주기 위해서 쿼리를 실행 중이다.
그렇다면 INACTIVE 세션은 무슨 일을 하기 위한 세션인가? 바로 AUTOTRACE 세션이다.
이 세션은 원래 세션을 지켜보다가 무엇을 하는지 보고하는 일을 수행한다.

SQL*Plus에서 AUTOTRACE 기능을 활성화할 때 SQL*Plus는 사용자가 DML 작업(INSERT, UPDATE, DELETE, SELECT, MERGE)을 실행할 때 다음과 같은 단계를 수행한다.
    1. 현재 커넥션을 이용하여 두 번째 세션이 존재하지 않는다면 새로운 세션을 생성한다.
    2. DML을 실행하는 세션의 초기 통계값을 기억하기 위해 SQL*Plus는 이 보조 세션에 V$SESSTAT 뷰를 조회하도록 요청한다.
        이것은 4장 '메모리 구조'에서 watch_stat.sql 스크립트가 수행했던 기능과 유사하다.
    3. SQL*Plus는 원래 세션에서 DML 작업을 실행한다.
    4. DML 문이 완료되면 SQL*Plus는 두 번째 세션에 다시 V$SESSTAT를 조회하도록 요청하고,
        DML을 수행한 세션에 대하여 이전과 다르게 나타는 수치를 보여주는 리포트를 생성한다.

AUTOTRACE 기능을 끄면, SQL*Plus는 이 부가 세션을 종료시키고 V$SESSION에서 이 세션을 더 볼수는 없다.
SQL*Plus는 왜 이런 편법을 사용하는가? 답은 매우 간단하다.
SQL*Plus는 4장 '메모리 구조'에서 메모리와 임시 공간(temporary spac) 사용량을 감시하기 위해 두 번째 세션을 사용했던 똑같은 이류로 부가 세션을 생성했다.
만약 메모리 사용량을 감시하기 위해 단일 세션을 하나 더 사용했다면, 감시하는 일에 또 다른 메모리를 사용했을 것이다.
단일 세션에서 통계(statistics)를 관찰한다면 반드시 통계를 보정해주어야 할 것이다.
SQL*Plus에서 수행한 I/O 수, 네트워크 상에서 전송된 바이트 수, 소트한 횟수를 리포트하기 위해 단일 세션을 사용한다면 이런 상세 정보를 알기 위해 사용된 쿼리의 통계가 원래 구하고자 했던 통계에 더해지게 된다(이 쿼리가 수행한 정렬, I/O 수행, 네트워크를 통한 데이터 전송 등일 수 있다).
그러므로 통계를 정확하게 측정하려면 별도의 세션(두 번째 세션)을 사용해야 한다.

이제까지 세션을 한 개 또는 두 개 가진 커넥션을 살펴보았다.
이제 세션이 없는 커넥션을 보기 위해 SQL*Plus를 사용하고자 한다.
이전 예에서 사용한 동일한 SQL*Plus 창에서 DISCONNET(이름을 잘못 붙인) 명령어를 입력하라.
SQL> disconnect
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

엄밀히 본다면 DISCONNECT 명령어 대신에 DESTROY_ALL_SESSIONS 명령어를 입력했어야 한다.
왜냐하면 DISCONNECT 명령어는 실제로 물리적인 커넥션을 끊는 명령어가 아니기 때문이다.

- Note --------------------------------------------------------------------------
SQL*Plus에서 진정한 의미의 disconnect는 'exit'다.
왜냐하면 커넥션을 완전히 끊는다는 것은 SQL*Plus에서 빠져 나가야 하기 때문이다.
---------------------------------------------------------------------------------

어쨌든, 위에서 사용하던 모든 세션을 닫았다.
다른 사용자의 계정으로 세션을 열고 쿼리하면 아래와 같다.
[oracle@sunshiny-net ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Tue May 15 15:29:23 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select * from v$session where username = 'SUNSHINY';

no rows selected

세션이 존재하지 않는 것을 볼 수 있지만, 여전히 물리적인 커넥션을 가진 프로세스를 갖고 있다(이전값 ADDR 값을 사용함).
SQL> select username, program
  2  from v$process
  3  where addr = hextoraw( '00000000D04DDEE0' );

USERNAME        PROGRAM
--------------- ------------------------------------------------
oracle          oracle@sunshiny-net (TNS V1-V3)

그렇게 함으로써 관련된 세션이 존재하지 않는 커넥션을 갖게 된다.
현재 존재하는 프로세스에 새로운 세션을 만들기 위해 또 한 번 이름을 잘못 붙인 SQL*Plus의 CONNECT 명령어를 사용할 수 있다(CONNECT 명령어를 CREATE_SESSION으로 명명했다면 훨씬 이해하기 쉬웠을 것이다).
DISCONNECT 명령어를 입력했던 SQL*Plus 인스턴스에서 다음을 실행해보자.
SQL> select username, sid, serial#, server, paddr, status
  2     from v$session
  3     where username = USER ;

USERNAME               SID    SERIAL# SERVER    PADDR                 STATUS
------------------------------- ---------- --------- ---------------- --------
SUNSHINY                 18        230 DEDICATED 00000000D04DDEE0   ACTIVE

이전과 동일한 PADDR 값으로 보건대, 우리는 같은 물리적 커넥션을 사용하고 있지만(잠재적으로) 다른 SID를 갖고 있다는 것에 주목하라.
필자는 같은 SID를 할당받을 수도 있기 때문에 잠재적으로란 말로 언급했으며, 이는 우리가 로그아웃한 사이에 다른 사람이 로그인했는지와 이전에 사용한 본래의 SID가 이용 가능한지에 달렸다.

이제까지는 dedicated server 커넥션을 사용하여 테스트를 수행했으므로 PADDR은 dedicated server 프로세스의 주소였다.
shared server를 사용하면 어떻게 될까?

- Note --------------------------------------------------------------------------
shared server를 통해 연결하기 위해서는 데이터베이스 인스턴스를 shared server에 필요한 설정으로 데이터베이스 인스턴스를 시작해야 한다.
---------------------------------------------------------------------------------
Shared Server 설정
SQL> alter system set shared_servers = 5;

System altered.

SQL> alter system set dispatchers="(protocol=tcp)(dispatchers=3)" ;

System altered.

SQL> !ps -ef | grep oracle
-- shared server 5 개 생성 확인 : s000 ~ s004
oracle   13618     1  0 09:02 ?        00:00:00 ora_s000_ora11g
oracle   12559     1  0 15:55 ?        00:00:00 ora_s001_ora11g
oracle   12561     1  0 15:55 ?        00:00:00 ora_s002_ora11g
oracle   12563     1  0 15:55 ?        00:00:00 ora_s003_ora11g
oracle   12565     1  0 15:55 ?        00:00:00 ora_s004_ora11g
-- dispatcher 3개 생성 확인 : d000 ~ d002
oracle   13616     1  0 16:01 ?        00:00:00 ora_d000_ora11g
oracle   13486     1  0 16:01 ?        00:00:00 ora_d001_ora11g
oracle   13488     1  0 16:01 ?        00:00:00 ora_d002_ora11g

SQL> !lsnrctl services

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 15-MAY-2012 16:08:17

Copyright (c) 1991, 2009, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
Services Summary...
Service "ora11gXDB" has 1 instance(s).
  Instance "ora11g", status READY, has 0 handler(s) for this service...
Service "oracle11g" has 1 instance(s).
  Instance "ora11g", status READY, has 4 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:5 refused:0 state:ready
         LOCAL SERVER
      "D000" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: sunshiny-net, pid: 13616>
         (ADDRESS=(PROTOCOL=tcp)(HOST=sunshiny-net)(PORT=40471))
      "D001" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: sunshiny-net, pid: 13486>
         (ADDRESS=(PROTOCOL=tcp)(HOST=sunshiny-net)(PORT=54127))
      "D002" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: sunshiny-net, pid: 13488>
         (ADDRESS=(PROTOCOL=tcp)(HOST=sunshiny-net)(PORT=40410))
The command completed successfully


- Oracle Clint 의 tnsnames.ora 파일 수정
SUNSHINY-NET =
  (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS =(PROTOCOL=TCP)(HOST=192.168.1.20)(PORT=1521))
      )
    (CONNECT_DATA =
        (SERVER = SHARED)
        (SERVICE_NAME=oracle11g)
    )
  )

- 세션 정보 확인
SQL> select username, program
  2  from v$process
  3  where addr = hextoraw( '00000000D04E60E0' );

USERNAME        PROGRAM
--------------- ------------------------------------------------
oracle          oracle@sunshiny-net (S004)

SQL> select username, program
  2  from v$process
  3  where addr = hextoraw( '00000000D04EA1E0' );

USERNAME        PROGRAM
--------------- ------------------------------------------------
oracle          oracle@sunshiny-net (D002)


-- Shared server
SQL> 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 = 'SUNSHINY'
  6  /

USERNAME           SID    SERIAL# SERVER    PADDR                 STATUS   PROGRAM
---------------------------- ---------- --------- ---------------- -------- ----------
SUNSHINY            21      565      SHARED    00000000D04E60E0     ACTIVE oracle@sunshiny-net (S004)

shared server 커넥션은 한 개의 프로세스와 관련되어 있다(PADDR이 존재하고 프로세스의 이름을 얻기 위해서 V$PROCESS와 조인할 수 있다).
이 경우 프로세스가 shared server라는 것을 문자열 S004을 통해 알 수 있다.

하지만 현 shared server 세션은 idle 상태로 놔둔 채 또 다른 SQL*Plus 창을 띄어 동일한 종류의 정보를 쿼리하면 다음과 같은 결과를 볼 수 있다.
-- Dispatcher
SQL> 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 = 'SUNSHINY'
  6  /

USERNAME           SID    SERIAL# SERVER    PADDR            STATUS   PROGRAM
---------------------------- ---------- --------- ---------------- -------- ----------
SUNSHINY            21        565 NONE      00000000D04EA1E0 INACTIVE oracle@sunshiny-net (D002)

PADDR 도 달라졌지만 관련된 프로세스 이름 또한 바뀌었다.
idle 상태에 있는 shared server 커넥션은 이제 dispatccher D002와 관련되어 있다.
따라서 단일 프로세스를 가리키는 다수의 세션을 관찰하기 위한 다른 방법은 아직 없다.
dispatcher는 자신을 가리키는 수백, 수천 개의 세션을 가질 수 있기 때문이다.

shared server 커넥션이 가지는 또 다른 흥미로운 특징은 호출이 일어날 때마다 사용하는 shared server 프로세스가 달라질 수 있다는 것이다.


출처 : 전문가를 위한 오라클 데이터베이스 아키텍처 - 토마스 카이트


※ 위 내용은, 여러 자료를 참고하거나 제가 주관적으로 정리한 것입니다.
   잘못된 정보나 보완이 필요한 부분을, 댓글 또는 메일로 보내주시면 많은 도움이 되겠습니다.
05 15, 2012 16:55 05 15, 2012 16:55


Trackback URL : http://develop.sunshiny.co.kr/trackback/752

Leave a comment


Recent Posts

  1. HDFS - Python Encoding 오류 처리
  2. HP - Vertica ROS Container 관련 오류...
  3. HDFS - Hive 실행시 System Time 오류
  4. HP - Vertica 사용자 쿼리 이력 테이블...
  5. Client에서 HDFS 환경의 데이터 처리시...

Recent Comments

  1. Generally I do not read post on bl... 레기읏룸 셔츠룸 차이. 레깅스룸 부엉이 01 24,
  2. Wonderful site. A lot of useful in... /427 01 23,
  3. 안녕하세요^^ 배그핵
  4. 안녕하세요^^ 도움이 되셨다니, 저... sunshiny
  5. 정말 큰 도움이 되었습니다.. 감사합... 사랑은

Recent Trackbacks

  1. cabo packages cabo packages %M
  2. airbnb host insurance airbnb host insurance %M
  3. beaches in cabo beaches in cabo %M
  4. joe’s dj service joe’s dj service %M
  5. short term rental property insurance short term rental property insurance %M

Calendar

«   01 2020   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Bookmarks

  1. 위키피디아
  2. MysqlKorea
  3. 오라클 클럽
  4. API - Java
  5. Apache Hadoop API
  6. Apache Software Foundation
  7. HDFS 생태계 솔루션
  8. DNSBL - Spam Database Lookup
  9. Ready System
  10. Solaris Freeware
  11. Linux-Site
  12. 윈디하나의 솔라나라

Site Stats

TOTAL 2824816 HIT
TODAY 435 HIT
YESTERDAY 443 HIT