서버 프로세스 : dedicated server / shared server
백그라운드 프로세스 : 데이터베이스 시작 / 디스크 블록 쓰기 / 온라인 리두 로그 유지 / 갑자기 중단된 프로세스 정리 / AWR 유지 등 데이터베이스 유지를 위한 다양한 태스크 수행
슬레이브 프로세스 : 백그라운드 프로세스와 유사하지만 대신해서 추가 작업 수행 프로세스
Oracle Net은 오라클이 클라이언트/서버 처리를 하기 위해 사용하는 네트워킹 소프트웨어/프로토콜
클라이언트와 서버가 같은 장비에 존재하더라도 이 두 프로세스 아키텍처는 여전히 사용되는데
이 것은 만약 클라이언트 프로세스와 서버 프로세스가 물리적으로 함께 링크될 경우 클라이언트 프로세스의 잘못된 포인터가 SGA에 있는 자료 구조를 쉽게 망가뜨리는 것을 방지할 수 있다ㅣ
Client-side
- Application : Sqlplus 등의 어플리케이션 프로그램이 DB에 접속 시에 사용되는 프로그램 계층
- OCI : Oracle Call Interface는 Server 프로세스가 하는 일에 대한 인터페이스 역할을 해주는 계층
- TTC(Two Task Common) : 문법적인 변환 기능을 해주는 계층
- ONF : TNS(Transparent Network Substrate) 계층으로 사용자위치와 서버위치 분석 및 인터럽트 처리 데이터의 암호화와 보호 기능을 담당
- OPA(Oracle Protocol Adaptor) : ONF 계층과 아래의 Protocol 계층의 매핑 역할
- Protocol : 클라이언트에서 데이터를 주고 받기 위해 사용되는 Protocol 지원 계층
Server-side
- Server : Client에서 실행되는 SQL 문과 OCI에 의해 호출되는 것들의 Response 담당
- OPI : Client 레벨의 OCI 요구 내용을 처리한 후 응답하는 계층
- TTC : 문법적인 변환 기능을 해주는 계층
- ONF : TNS계층으로 사용자위치와 서버 위치 분석 및 인터럽트 처리 데이터의 암호화와 보호 기능을 담당
- OPA : Server 레벨의 TNS 계층과 Protocol 계층의 매핑을 시켜주는 계층
- Protocol : 클라이언트에서 데이터를 주고 받기 위해 사용되는 Protocol 지원 계층
유닉스에서 리스너를 통해 fork(), exec() system call을 거쳐 새로운 dedicated server를 획득 이는 비용이 매우 큰 작업이므로 하나 혹은 일련의 SQL문을 수행하기 위해 매번 연결요청을 한다면 성능이 좋을리가 없다 오라클에 접속하는 애플리케이션을 구축할 때 반드시 커넥션 풀 기능이 필요한 이유가 여기에 있다 한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 반복 재사용한다 이것은 재사용성이라는 관점에서 데이터베이스 성능 뉴팅의 핵심 원리이기도 하다
윈도우에서는 IPC(interprocess communication)를 호출하여 decicated server를 생성
새로운 dedicated server 프로세스는 리스너에 의해 커넥션 권한을 상속받아 데이터베이스에 물리적인 커넥션을 하게 된다
Shared server는 리스너는 인스턴스에서 운영중인 dispatcher 프로세스에 대한 정보를 가지고 있고 접속 요구를 받으면 리스너가 현재 사용 가능한 dispatcher들의 pool에서 한 개의 dispatcher 프로세서를 선택하고 이 커넥션 정보를 클라이언트에 보내주고 dispatcher 프로세스에 연결 요청을 넘긴다 디스패처는 서버에 랜덤하게 포트를 할당하여 커넥션을 수락하고 리스너는 이 정보를 알고 있다 그래서 리스너가 랜덤포트를 사용자에게 알려주고 사용자는 이제 리스너를 거치지 않고 바로 디스패처에 접속한다
|
SYS@orcl>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);
+ DEDICATED_SERVER CLIENTPID ------------------------ ------------------------ 4911 4807
SYS@orcl>!/bin/ps -fp 4911 4807 UID PID PPID C STIME TTY STAT TIME CMD oracle 4807 4806 0 10:19 pts/5 Ss+ 0:00 sqlplus as sysdba oracle 4911 4807 0 10:19 ? Ss 0:01 oracleorcl (DESCRIPTION=(LOCAL=YE |
Dedicated server와 관련된 프로세스 ID를 보기 위해 쿼리를 사용했고 bin/ps-fp의 결과는 부모 PPID를 포함하고 있으며 4911이 4807의 자식이라는 것을 알 수 있다.
Shared server 커넥션은 클라이언트와 서버가 동일한 장비에 있더라도 Oracle Net를 강제적으로 사용한다 ( TNS 리스터를 사용해야 shared server를 사용할 수 있다) 클라이언트 어플리케이션은 오라클 TNS 리스너에 연결한 다음 디스패처로 방향을 바꾸고 요청을 넘긴다 디스패처는 클라이언트와 shared server 프로세스 간에 파이프처럼 작동한다
한 개의 인스턴스에 여러 개의 디스패처를 둘 수 있고 단순히 클라이언트가 보낸 요청을 받아서 SGA의 request queue에 넣는 역할을 수행하고 미리 생성되니 쉐어 서버 프로세스 중에서 첫번째로 가용된 쉐어 서버 프로세스는 큐로부터 요청을 꺼내서 response queue에 넣는다 디스패처는 항상 응답 큐를 감시하다 해당 요청에 대한 결과를 찾으면 클라이언트에 되돌려준다
커넥션과 세션
오라클에서 커넥션은 단순히 클라이언트 프로세스와 데이터베이스 인스턴스간의 물리적인 경로(대개는 네트워크 커넥션)다
세션은 인스턴스에 존재하는 논리적인 개체며 세션의 상태와 사용자의 세션을 유일하게 표현하는 것으로 사용자는 서버에 존재하는 세션에서 SQL을 실행하고 트랜잭션을 커밋하는 작업을 수행한다
|
SYS@orcl>select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 /
USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- SYS 9 3 DEDICATED 384CB63C ACTIVE
SYS@orcl>set autotrace on statistics SYS@orcl>select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 /
USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- SYS 9 3 DEDICATED 384CB63C ACTIVE SYS 19 25 DEDICATED 384CB63C INACTIVE
Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 0 consistent gets 0 physical reads 0 redo size 817 bytes sent via SQL*Net to client 419 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 2 rows processed |
두 개의 세션이 존재하지만 둘 다 똑 같은 PADDR 값을 가진것으로 봐서 같은 dedicated server 프로세스를 사용하는 것을 알 수 있다 별도의 프로세스를 생성치 않고 한 개의 프로세스(두 개의 세션 모두 한 개의 커넥션)만 사용하고 있다는 것을 확인할 수 있고 여기서 SQL 실행문은 ACTIVE 상태며 세션 정보를 보여주기 위해 쿼리를 실행중이고 INACTIVE는 AUTOTRACE 세션이다 이 세션은 세션을 지켜보다 무엇을 하는지 보고 하는 일을 수행한다
우리가 SQL PLUS에서 AUTOTRACE 기능을 활성화하면 SQL PLUS는 사용자의 DML 작업을 실행할때 다음의 단계를 수행한다
1. 현재 커넥션을 이용해서 새로운 세션을 생성
2. DML을 실행하는 세션의 초기 통계값을 기억하기 위해 SQLPLUS는 이 보조 세션에 V$SESSTAT뷰를 조회하도록 요청
3. 원래 세션은 DML 작업 수행
4. DML문이 완료되면 SQL PLUS는 두 번째 세션에 V$SESSTAT를 조회하도록 요청하고 이전과 다르게 나타는 수치를 보여주는 리포트를 생성
이렇게 단일 커넥션에 두 개의 세션을 만드는 이유는 메모리 사용량 감시시 또 다른 메모리를 사용하지 않기 위해서다 그리고 단일 세션에서 통계를 관찰할 경우 상세 정보를 알기 위해 사용된 쿼리의 통계가 원래 구하고자 했던 통계에 대해지면서 원하는 정확한 통계가 나오지 않게 된다 그러므로 통계를 정확하게 측정하려면 같은 커넥션에 별도의 세션을 사용해야 한다
|
SYSTEM@orcl_s>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 = 'SYSTEM'; USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- PROGRAM ------------------------------------------------ SYSTEM 176 80 SHARED 384CAB64 ACTIVE oracle@lnx04.ocmkorea.com (S002)
SYSTEM@orcl_s>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 = 'SYSTEM';
USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- PROGRAM ------------------------------------------------ SYSTEM 176 80 NONE 384C8004 INACTIVE oracle@lnx04.ocmkorea.com (D000)
SYSTEM 178 33 SHARED 384CAB64 ACTIVE oracle@lnx04.ocmkorea.com (S002) |
|
TIGER@orcl_s>exec dbms_lock.sleep(20);
SYSTEM@orcl_s>/
USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- PROGRAM ------------------------------------------------ SYSTEM 176 80 SHARED 384C95B4 ACTIVE oracle@lnx04.ocmkorea.com (S000)
TIGER@orcl_s>exec dbms_lock.sleep(20);
PL/SQL procedure successfully completed.
SYSTEM@orcl_s>/ USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- -------- -------- PROGRAM ------------------------------------------------ SYSTEM 176 80 SHARED 384CAB64 ACTIVE oracle@lnx04.ocmkorea.com (S002) |
처음 A세션에서 쿼리시에는 S002였고 다른 B 세션에서 shared server를 독점하는 문장을 실행했는데 같은 S002를 할당 받았고 그렇기 때문에 다시 A 세션에서 쿼리를 실행할 경우 S000을 할할 받은 것을 알 수 있다 그리고 B세션에서 독점하는 문장이 끝나고 A세션에서 쿼리를 실행하면 처음 할당받았던 S002로 돌아간걸 알 수 있다.
다수의 shared server가 개별 문장을 분담해서 처리하는 것을 알 수 있다.
Dedicated Server vs Shared Server
Dedicated Server
일대일 매핑이기 때문에 장기간 수행되는 트랜잭션이 다른 트랜잭션을 방해할 일도 없고 다른 트랜잭션은 단지 자신만의 전용 프로세스를 통해 작업한다 그러므로 장기간 트랜잭션을 수행하는 배치환경(non-OLTP)에서 사용할 수 있는 유일한 모드
오라클에서 추천하는 구성이며 확장도 좀 더 용이하다 데이터베이스를 시작하고 종료하는 특정 작업은 반드시 dedicated server 모드에서 처리되어야 하므로 오라클의 모든 데이터베이스는 dedicated server 모드로만 설치되거나 shared mode와 함께 dedicated server 모드를 병행해서 설치해야 한다
Shared server
dedicated server 모드와 shared server 모드의 주요 차이점은 설정보다는 수행 모드에 있다 다대일 관계로서 shared server는 공유 자원을 사용한다 그러므로 장기간 독점하지 않도록 주의해야 하며 앞에서 했던 dbms_lock.sleep(20) 문장만 해도 shared server 프로세스를 무려 20초간 독점하게 되기에 이런 처리를 지양해야 한다
shared server를 도입할 때 가장 중요하게 고려해야하는 건 트랜잭션의 지속 시간이 짧다는 확신이다 OLTP처럼 자주 트랜잭션을 수행할 수는 있지만 수행하는 시간은 짧아야 한다 극단적인 경우 모든 shared server가 바쁘다면 독점하고 있는 몇몇을 제외한 모든 사용자에게는 시스템이 멈춘 것처럼 보인다
shared server에 사용할 트랜잭션의 유형을 잘 선택한다는 가정하에 가지는 잠재적인 이점은 세가지가 있는데
1. OS에서 프로세스나 쓰레드 개수를 감소시키고
2. 인위적으로 동시성의 정도를 제한하고
3. 시스템에 필요한 메모리량을 감소시킨다
수천명의 사용자를 가진 시스템에서 운영체제가 수천개의 프로세스를 관리하려 한다면 금방 감당하기 어려운 상태가 될 수 있다 일반적인 시스템에서는 어느 시점에 동시에 활동하는 사용자 수는 수천명 중 일부에 불과할 것이다 만약 5000여명 정도의 사용자를 가진 시스템에서 특정 시점에 동시 접속자가 50명 정도 된다고 한다면 이 시스템은 운영체제가 관리해야 하는 프로세스 개수를 1/100으로 줄이면서 50개의 shared server 프로세스만 갖고 있더라도 효과적으로 작동했을 것이다
동시 사용자 수와 초당 처리할 수 있는 트랜잭션의 수를 벤치마킹한다면 초기에는 동시사용자수에 비례해서 트랜잭션의 수도 증가하는데 어느 시점부터는 사용자가 추가로 늘어난다고 해도 트랜잭션의 수가 증가하지 않고 오히려 처리량이 최고점에 도달하면 응답시간이 증가하기 시작하고 사용자 역시 응답시간이 느려지는걸 느낄 수 있다 계속해서 사용자 수가 늘어나면 처리량이 하락하게 되고 이 하락하기 전에 측정한 동시 사용자 수가 시스템이 허용하는 최고점이다 이 최고점을 넘어서면 시스템은 사용자들로 넘쳐나고 큐는 작업을 수행하기 위해 대기 작업들이 쌓이기 시작한다 이는 제 성능 유지가 안되며 응답시간의 증가 및 잦은 컨텍스트 스위칭 발생으로 시스템의 처리량이 급격히 하락하게 된다
하락하기 바로 직전 값으로 최대 동시성을 제한한다면 최대 처리량을 유지할 수 있고 사람들의 응답시간 증가를 최소화할 수 있다 shared server는 이 값을 시스템의 최대 동시성을 제한하는 것을 권장한다
이 과정을 문을 이용하는 방식으로 설명하면 문의 폭과 사람의 폭이 분당 지나갈 수 있는 사람의 수를 제한하는데 이때 시스템 부하가 작을 때는 문제가 되지 않는다 그러나 좀 더 많은 사람들이 문을 통과하려면 일부 사람은 강제로 기다려야 한다(CPU time slice) 이 때 큐를 이용한 모델(shared server)이 처리량에 있어서 다른 무질서한 접근 모델보다 훨씬 낫다
시스템에 필요한 메모리량 줄이기
shared server에서 UGA는 SGA에 위치하게 되는데 예상되는 UGA 메모리 수요를 정확하게 결정해서 LARGE_POOL_SIZE 파라미터를 이용해 SGA에 적절하게 할당할 수 있어야 한다 shared server는 dedicated server보다 훨씬 적은 수의 PGA를 할당받게 되는데 PGA는 프로세스 정보를 담고 있고 이 공간을 shared server가 사용하게 됨으로써 그 양을 절약할 수 있다 만약 5000개의 dedicated server를 사용하다 100개의 shared server를 사용하게 되면 4900개의 PGA가 필요 없어진다
백그라운드 프로세스
데이터베이스를 지속적으로 수행하는데 필요한 일상적인 유지 업무를 담당
|
SYS@orcl>select paddr, name, description from v$bgprocess 2 where paddr <>'00' 3 order by paddr desc;
PADDR NAME DESCRIPTION -------- ----- ---------------------------------------------------------------- 384D385C CJQ0 Job Queue Coordinator 384D0224 QMNC AQ Coordinator 384CF74C ARC3 Archival Process 3 384CEC74 ARC2 Archival Process 2 384CE19C ARC1 Archival Process 1 384CD6C4 ARC0 Archival Process 0 384CC114 SMCO Space Manager Process 384C752C MMNL Manageability Monitor Process 2 384C6A54 MMON Manageability Monitor Process 384C5F7C RECO distributed recovery 384C54A4 SMON System Monitor Process 384C49CC CKPT checkpoint 384C3EF4 LGWR Redo etc. 384C341C DBW0 db writer process 0 384C2944 MMAN Memory Manager 384C1E6C DIA0 diagnosibility process 0 384C1394 PSP0 process spawner 0 384C08BC DBRM DataBase Resource Manager 384BFDE4 DIAG diagnosibility process 384BF30C GEN0 generic0 384BE834 VKTM Virtual Keeper of TiMe process 384BDD5C PMON process cleanup |
인스턴스 시작 후 프로세스들
|
SYS@orcl>!ps -aef | grep ora_...._$ORACLE_SID | grep -v grep oracle 4818 1 0 10:19 ? 00:00:00 ora_pmon_orcl oracle 4822 1 0 10:19 ? 00:00:01 ora_vktm_orcl oracle 4828 1 0 10:19 ? 00:00:00 ora_gen0_orcl oracle 4832 1 0 10:19 ? 00:00:00 ora_diag_orcl oracle 4836 1 0 10:19 ? 00:00:00 ora_dbrm_orcl oracle 4840 1 0 10:19 ? 00:00:00 ora_psp0_orcl oracle 4844 1 0 10:19 ? 00:00:10 ora_dia0_orcl oracle 4848 1 0 10:19 ? 00:00:00 ora_mman_orcl oracle 4852 1 0 10:19 ? 00:00:00 ora_dbw0_orcl oracle 4856 1 0 10:19 ? 00:00:00 ora_lgwr_orcl oracle 4860 1 0 10:19 ? 00:00:10 ora_ckpt_orcl oracle 4864 1 0 10:19 ? 00:00:00 ora_smon_orcl oracle 4868 1 0 10:19 ? 00:00:00 ora_reco_orcl oracle 4872 1 0 10:19 ? 00:00:02 ora_mmon_orcl oracle 4876 1 0 10:19 ? 00:00:01 ora_mmnl_orcl oracle 4880 1 0 10:19 ? 00:00:00 ora_d000_orcl oracle 4884 1 0 10:19 ? 00:00:00 ora_d001_orcl oracle 4888 1 0 10:19 ? 00:00:00 ora_s000_orcl oracle 4892 1 0 10:19 ? 00:00:00 ora_s001_orcl oracle 4896 1 0 10:19 ? 00:00:00 ora_s002_orcl oracle 4924 1 0 10:19 ? 00:00:00 ora_arc0_orcl oracle 4928 1 0 10:19 ? 00:00:00 ora_arc1_orcl oracle 4932 1 0 10:19 ? 00:00:00 ora_arc2_orcl oracle 4936 1 0 10:19 ? 00:00:00 ora_arc3_orcl oracle 4943 1 0 10:19 ? 00:00:00 ora_qmnc_orcl oracle 5005 1 0 10:19 ? 00:00:00 ora_q000_orcl oracle 5010 1 0 10:19 ? 00:00:00 ora_q001_orcl oracle 5092 1 0 10:24 ? 00:00:00 ora_smco_orcl oracle 10416 1 0 15:24 ? 00:00:00 ora_w000_orcl |
이 프로세스들은 동일한 이름을 가진 바이너리 실행 프로그램이라는 것이다 이 프로세스 모두 oracle이고(oracle은 바이너리 실행 파일의 이름) 데이터 베이스 구동시에 무슨 프레슷인지 식별하기 쉽게 하기 위하여 oracle을 자신들의 이름으로 바꾸어줄 뿐이다
이 이유는 유닉스 플랫폼이 대량의 객체 코드를 효율적으로 공유할 수 있도록 하기 위해서다
PMON
비정상적으로 커넥션이 종료된 것을 정리하는 일을 담당 dedicated server가 실패하거나 다른 특정한 이유로 죽으면 잘못도니 작업을 복구하거나 원상태로 되돌리고 자원을 해제한다 커밋되지 않은 작업에 대해 롤백하고 락을 해제하고 실패한 프로세스에 할당된 SGA 자원을 풀어준다
다른 오라클 백그라운드 프로세스를 모니터 하고 필요하다면(가능하다면) 프로세스를 재시작하는 일을 맡고 있다 모든 오라클 프로세스를 지켜보다 적절한 시점에 재시작시키거나 인스턴스를 종료시킨다
자신을 오라클 TNS 리스너에 등록하는 일이 있는데 인스턴스를 구동하면 알려진 포트번호로 폴링한다 데이터베이스가 구동할 때 리스너가 실행중이라면 PMON은 리스너와 연동하여 인스턴스의 서비스 이름, 부하 메트릭(metrics)같은 관련 파라미터를 리스너에 전달한다 실행 상태가 아닐 경우 1분 간격으로 자기 자신을 등록하려 한다
====================
폴링 : 한 프로그램이나 장치에서 다른 프로그램이나 장치들이 어떤 상태에 있는지를 지속적으로 체크하는 방식 그들이 아직도 접속되어 있는지와 데이터 전송을 원하는지 등을 체크
메트릭 : 경로 사용에 관련한 비용을 식별하는 특정 네트워크 인터페이스와 IP 경로에 할당된 값을 의미
=====================
SMON
시스템 레벨의 모든 작업을 수행하는 프로세스 PMON이 개별 프로세스에 관심을 가진다면 SMON은 시스템 레벨 관점으로 일을 바라보며 데이터베이스를 위한 garbage collector 역할을 수행
Temporary 공간 정리 : 진정한 temporary TBS의 등장으로 일은 줄었지만 아주 없지는 않다 인덱스 생성과정에서 만들어진 extent는 temporary로 표시되고 만약 create index 세션이 갑자기 중단 되면 SMON은 temporary로 표시된 익스텐트를 정리하는 일을 맡는다 다른 작업이 생성한 임시 익스텐트 또한 SMON이 맡아서 처리한다
빈 공간 합침 : dictorynary-manage SMON은 테이블스페이스에서 빈 익스텐트와 서로 인접한 익스텐트를 가져와서 한 개의 큰 빈 익스텐트로 합치는 일을 맡는다
RAC에서 실패한 노드의 인스턴스 복구를 수행 : RAC 구성에서 클러스터 내에 존재하는 데이터베이스 인스턴스가 실패하면(인스턴스가 실행 중인 장비가 실패한 경우) 클러스터 내에 존재하는 다른 노드가 실패한 인스턴스의 리두 로그 파일을 열어서 모든 데이터에 대한 복구 작업을 수행
OBJ$ 정리 : OBJ$ 테이블은 데이터베이스에서 거의 모든 객체(테이블,인덱스,트리거,뷰 등)에 대한 엔트리를 포함하고 있는 low-level 데이터 딕셔너리 테이블이다 삭제된 객체 엔트리 뿐만 아니라 현재는 더 이상 존재하지 않는 객체를 표현하는 엔트리를 갖고 있다 SMON은 OBJ$ 테이블에서 더 이상 필요하지 않은 이런 로우를 제거하는 프로세스
RECO(distributed database recovery) : 분산 데이터베이스 복구
2PC(two-phase commit 2단계 커밋)를 하는 동안 장비가 멈춰 서거나 커넥션 손실 때문에 준비 상태로 남아 있는 트랜잭션을 복구한다 2PC는 많은 이기종 데이터베이스에 영향을 미치는 변경을 원자적(atomically)으로 커밋하는 분산 프로토콜이다
=====================
원자적 커밋이란 단일 동작에 있어 구별되는 변경사항의 세트가 적용되는 하나의 동작을 말한다 변경 사하들이 적용되고 나면 원자적 커밋이 성공했다고 한다 만약 실패할 경우 원자적 커밋 내에서 완료된 모든 변경사항들은 다시 되돌려진다 이것이 가능케 하는 점은 시스템이 항상 안정적인 상태에 있다는 것을 확신시켜준다는 것이다 분리에 대한 또 다른 중요한 점은 원자적 작업의 특징에서 비롯된다 이러한 분리성은 한번에 단 한 개의 원자적 커밋만이 처리된다는 것을 보장
=======================
N개의 데이터베이스가 참여하는 2PC에서는 데이터베이스 중 하나가(항상 그렇지 않지만 클라이언트가 초기에 로그인 한 데이터베이스) 코디네이터가 된다 이 사이트가 다른 N-1 사이트로 커밋할 준비를 체크하고 N-1개의 각 사이트는 준비 상태 여부를 응답한다 만약 하나의 사이트라도 NO라고 응답하면 전체 트랜잭션은 롤백한다 만약 모두 YES라고 응답하면 코디네이터 사이트는 N-1개 각 사이트로 영구적으로 커밋하도록 메시지를 전송한다
만약 어떤 사이트가 YES라고 응답한 다음 커밋하는 준비 도중 코디네이터로부터 커밋 지시를 받기도 전에 네트워크가 실패하거나 여타 오류가 발생하면 이 트랜잭션은 in-doubt 분산 트랜잭션이 된다
==============================
In-doubt transaction
DDB Transaction은 2PC Commit를 사용한다 즉 2개의 다른 DB에 트랜잭션이 연결되어 있으면 DDB Transaction이 되는 것이다 이때는 2개의 DB 모두 커밋되거나 롤백되어야 하는데 2개를 동시에 할 수 없으므로 하나씩 하고 하나는 나중에 잘 되었는지 검사를 한다 만약 둘 다 커밋이 되야 하는데 첫번째것은 커밋이 되고 두번째 것은 error로 인해 커밋이 안되면 첫번째 것은 in-doubt 트랜잭션이 되는 것이다 이것은 나중에 롤백된다
===============================
바로 이때 실패한 in-doubt 트랜잭션은 RECO의 책임이 된다 RECO 해당 트랜잭션의 결과를 알기 위해 코디네이터와 접촉을 시도하고 RECO가 코디네이터와 접촉을 하기 전까지 해당 트랜잭션은 커밋되지 않은 상태로 남아 있고 RECO가 트랜잭션 코디네이터와 다시 접촉하면 해당 트랜잭션을 커밋하거나 롤백한다
CKPT 체크포인트 프로세스
체크포인트를 직접하지는 않는다 체크포인트 작업은 대부분 DBWn의 작업이고 CKPT는 데이터 파일의 파일 헤더를 수정하여 체크포인트를 직접 수행하는 프로세스를 도와줄 뿐이다 데이터파일과 헤더와 컨트롤 파일의 동기화를 위한 SCN을 생성한다
DBWn
Dirty 블록을 디스크에 기록하는 일을 담당하는 백그라운드 프로세스 버퍼 캐시에 빈 공간을 만들기 위해 캐시에 있는 더티 블록을 디스크로 내려 쓰거나 체크포인트를 전진시킨다(인스턴스가 실패하면 오라클이 인스턴스를 복구하기 위해 온라인 리두 로그 파일에서 읽기 시작하는 지점을 앞으로 이동시킨다) 만약 리두 로그 파일을 재사용해야 하는데 체크포인트를 앞으로 이동시킬 수 없다면 checkpoint not complete 메시지를 받게 된다
로그 파일의 체크포인트 지점을 이동하는 일은 체크포인트 활동 중 일부분에 불과하다 FAST_START_MTTR_TARGET 같은 파라미터와 dirty 블록을 디스크로 플러시하는 트리거에 의해 제얻되는 점증적(점진적)인 체크포인트도 존재한다
DBWn의 성능은 매우 중요하다 블록을 디스크에 기록하는 속도가 다른 블록을 캐시하기 위해 버퍼를 비우는 속도를 따라가지 못하면 Free buffer Waits 대기 횟수와 Write Complete Waits 대기 시간이 증가한다
DBWn은 한 개 이상 구성할 수 있고 대부분의 시스템은 보통 하나만 실행하지만 멀티 CPU 시스템에서는 두 개 이상 실행할 수 있다 이것은 SGA에 있는 대용량 블록 캐시를 깨끗하게 유지하고 변경된 블록을 디스크로 플러시하는 워크로드를 분산하는데 사용된다
디스크에 블록을 쓰는데 선택적으로 비동기 I/O를 사용하는데 디스크에 기록할 일정 개수의 블록을 수집하고 이것을 OS에 넘긴다 OS가 실제로 그 블록을 모두 디스크에 쓸 때까지 기다리지 않고 바로 돌아와서 OS에 넘겨줄 다음 블록을 수집한다 OS가 쓰기 연산을 완료하면 DBWn에 작업이 완료됬음을 알려준다 DBWn은 순차적으로 작업할 때보다 훨씬 빠르게 작업을 수행할 수 있다
DBWn은 디스크 곳곳에 흩어져 있는 블록을 갱신한다(산발적 쓰기<scattered writes>작업을 훨씬 더 많이 수행) 데이터를 수정할 때 인덱스 블록과 랜덤하게 분산 되있는 데이터 블록을 변경한다반면 LGWR 리두 로그에 순차적인 쓰기 작업을 더 많이 수행한다 이것이 가장 중요한 차이점이며 오라클이 DBWn 프로세스 뿐만 아니라 리두 로그와 LGWR 프로세스를 따로 가지고 있는 이유 중 하나다 산발적 쓰기는 순차적쓰기보다 현저히 느리다 그래서 DBWn 프로세스가 SGA버퍼의 dirty 블록을 디스크에 기록할 수 있도록 LGWR 프로세스가 대규모 순차적인 쓰기를 함으로써 성능 향상을 달성할 수 있다 사용자가 대기하는 동안 DBWn은 백그라운드에서 느린 작업을 수행하고 LGWR는 좀 더 빠른 작업을 수행한다는 사실은 전체적으로 더 나은 성능을 기대하는 것을 의미한다
LGWR 로그 Writer
SGA에 위치한 리두 로그 버퍼의 내용을 디스크에 플러시한다
- 3초마다
- commit시
- 리두 로그 버퍼가 1/3 채워지거나 버퍼에 저장 데이터를 1MB 담고 있을 때
오라클은 훨씬 자주 그리고 지속적으로 리두 로그 버퍼를 플러시하기 때문에 리두 로그 버퍼의 전체 공간을 사용할 수는 없을 것이다 순차적 I/O를 이용하여 변경된 바이트를 쓰는 작업의 효율성은 이후 초래될 추가 I/O보다 춸씬 크다
ARCn 아카이브 프로세스
LGWR이 온라인 리두 로그 파일을 채울 시 다른 위치로 복제하는 일을 담당한다 미디어 복구 시 사용되며 아카이빙된 리두 로그는 하드 디스크에 장애가 발생했을 때 데이터 파일을 수정하기 위해 사용될 수 있다
Diag 진단 프로세스
RAC에서만 사용되다 11g에서 새롭게 등장한 ADR(Advanced Diagnostic Repository) 프로세스와 함께 인스턴스의 전체적인 상태를 모니터하는 책임을 맡게 됬다 인스턴스의 장애를 처리하는데 필요한 정보를 캡처하고 이는 단일 인스턴스 구성에도 똑같이 적용된다
FBDA : 플래시백 데이터 아카이버 프로세스
11gR1에서 등장하는 프로세스로 플래시백 데이터를 아카이빙하는 새롭게 추가된 기능을 담당하는 중요한 요소 중 하나다 장기간에 걸친 데이터의 이력을 쿼리할 수 있는 기능은 시간에 따라 테이블의 모든 로우에 일어난 변화를 이력으로 관리함으로써 달성될 수 있다 백그라운드에서 데이터에 대한 이력을 순서대로 유지 및 관리한다 FBDA는 트랜잭션 커밋후에 곧바로 작업을 수행하며 해당 트랜잭션이 생성한 UNDO를 읽고 변경한 내용을 롤백한다 그런 다음에 롤백한 로우(변경이전의 값을 갖고 있는)를 플래시백 데이터 아카이브에 기록할 것이다
DBRM : 데이터베이스 리소스 관리자 프로세스
특정 데이터베이스의 인스턴스를 위해 설정된 자원 계획을 수행한다 DBRM은 자원 계획을 세우고 시행하는 일에 관련된 작업을 수행하는데 자원관리자인 DBR은 관리자가 사용하는 인스턴스 액세스하는 애플리케이션 또는 개별 사용자가 사용하는 자원에 대해 세밀하게 제어한다
GEN0 : 일반적인 태스크 실행 프로세스
GEN0(general task execution) 프로세스는 태스크를 실행하는 쓰레드를 제공한다 GEN0 프로세스의 주요 목적은 다른 프로세스로 인해 일어날 수 있는 잠재적인 블로킹 과정(이것이 발생하는 동안 프로세스를 멈추게 하는 과정)을 줄이는 일을 백그라운드에서 수행한다
특화된 프로세스
지금부터 언급될 프로세스는 특정 기능을 사용할 때만 나타난다
ASMB(auto storage management background) ASM을 사용하는 인스턴스에서만 실행된다 ASMB는 전체 스토리지를 관리하는 ASM 인스턴스에 연결하여 시간에 따라 변경되는 통계를 제공하고 ASM의 상태를 체크하는 heartbeat 신호를 ASM 인스턴스에 제공하는 책임을 맡고 있다
RBAL(ReBALance) 프로세스 : RBAL 프로세스 또한 ASM을 사용하는 데이터베이스 인스턴스에서 실행되며 ASM 디스크 그룹에서 디스크를 추가하거나 제거할 때 rebalance 요청을 처리하는 책임을 맡고 있다
RAC 인스턴스에서 볼수 있는 것들이다 RAC는 읽기-쓰기가 모두 가능한 유형으로 한 개 이상의 인스턴스가 단일 데이터베이스 파일 집합을 액세스 할 수 있다 RAC의 주요 목적은 두가지다
높은 가용성 : 한 클러스터 내에 한 노드 또는 컴퓨터가 S/W, H/W 또는 인간의 실수로 장애가 발생한다면 다른 노드가 해당 기능을 계속해서 수행한다 다른 노드를 통해서도 데이터베이스 액세스가 가능하기 때문이다 어느 정도의 컴퓨팅 파워를 잃을 수 있지만 여전히 DB 액세스가 가능
확장성 : 계속 증가하는 작업 부하를 다루기 위해서 더 큰 장비를 구매할 수 있지만(수직적 확장 <vertical scaling>) RAC는 클러스터 내에 장비를 늘리는 방식 ( 수평적 확장 horizontal scaling) 으로 자원을 추가할 수 있다 다시 말해 CPU가 4개인 장비를 CPU가 8 또는 16개로 확장이 가능한 장비를 구매하는 대신에 RAC는 상대적으로 덜 비싼 다른 CPU가 4개인 장비를 추갛ㄹ 수 있는 옵션을 제공
Rac clusterware database sga resource 클러스터웨어가 각 노드의 리소스를 관리하고 각 노드별 사용하는 storage의 자원 역시 관리한다 노드간의 cluster interconnect로 연결되어 있다
Lock Monitor : LMON은 인스턴스의 장애를 감지하기 위해 클러스터에 있는 모든 인스턴스를 감시한다 특정 인스턴스에 장애가 발생하면 해당 인스턴스가 보유하고 있는 글로벌 락을 복구할 수 있다 또한 클러스터에 인스턴스를 추가한다거나 제거할 때 락과 여타 자원을 다시 구성하는 책임을 맡고 있다(인스턴스에 장애가 발생한 다음 다시 온라인 상태로 돌아올 때 또는 새로운 인스턴스가 실시간으로 클러스터가 추가할 때)
Lock Manager daemon LMD0 : LMD 프로세스는 서비스 요청을 받아서 인스턴스 간에 블록 버퍼의 일관성을 유지하면서 글로벌 캐시 서비스를 제공한다 LMD는 주로 LMSn 프로세스가 다루는 큐에 리소스에 대한 요청을 보내는 중재자(broker)역할을 담당 LMD는 글로벌 데드락 감지 및 해결을 다루고 글로벌 환경에서 락 타임아웃을 감시한다.
Lock Manager Server LMSn : RAC 환경에서 오라클의 각 인스턴스는 클러스터 내 각기 다른 장비에서 실행하며 읽기와 쓰기가 모두 가능한 방식으로 정확히 같은 데이터베이스 파일을 액세스한다 LMSn 프로세스의 주요 목적 중 하나는 서로 관련된 SGA 블록 버퍼 캐시의 일관성을 유지하는 일이다 이전 릴리즈에서 사용하던 오라클 병렬 서버(OPS, Oracle Parallel Server)는 ping을 통해서 일관성을 유지하였다 즉 클러스터를 구성하고 있는 한 노드가 다른 노드가 배타적으로 락을 건 블록에 대하여 읽기 일관적으로 액세스하기 위해서는 디스크 플러시(블록을 ping)를 통해서 데이터의 교환이 이루어졌다 이것은 단지 데이터를 읽기 위한 작업 치고는 비용이 많이 드는 작업이다 그러나 지금은 LMSn으로 데이터 교환이 클러스터의 고속 커넥션을 거쳐서 캐시간에 매우 빠르게 이루어진다 인스턴스당 10개까지 LMSn 프로세스를 띄울 수 있다.
Lock(LCK0) 프로세스 : LMD 프로세스와 기능적으로 매우 유사하지만 데이터베이스 블록 버퍼를 제외한 모든 글로벌 자원에 대한 요청을 취급
공통 백그라운드 프로세스
PSP0 프로세스 생성기 다양한 백그라운드 프로세스를 생성 또는 시작하는 책임을 맡고 있다 오라클 인스턴스를 위해 새로운 프로세스 또는 쓰레드를 생성하는 프로세스며 대부분 작업을 인스턴스 구동 시에 수행
VKTM Virtual Keeper of Time 가상 시간 유지기 프로세스는 오라클 인스턴스를 위해 일관적이며 세밀하게 분할한(find-grained) 클록을 제공한다 VKTM은 지속시간과 시간 간격을 측정하는데 사용되는 정밀도가 매우 높은 타이머뿐만 아니라 사람이 읽을 수 있는 wall clock time 둘 다 제공
SMCO Space Management Coordinator 공간 관리 조정자 프로세스 : SMCO 프로세스는 관리 인프라의 일부분으로 예를 들면 회수할 수 있는 공간을 발견하는 프로세스, 직접 해당 공간을 회수하는 프로세스 처럼 데이터베이스의 적극적인 공간 관리 기능을 조정
유틸리티 백그라운드 프로세스
필요에 따라 사용자가 선택할 수 있는 프로세스로 사용자가 직접 사용하지 않는 한 일일이 실행할 필요는 없다 유닉스에서 ps 명령어를 입력하면 유틸리티 프로세스를 볼 수 있다
Job queue를 구성했다면 CJQ0 프로세스가 job queue 조정자
오라클 AQ를 구성했다면 Q000(AQ 큐 프로세스)와 QMNC(AQ 모니터 프로세스)로 알 수 있다
자동 메모리 관리를 활성화 했다면 MMAN 프로세스로 알 수 있다
오라클 관리/진단 기능을 활성화 했다면 관리 모니터 MMON와 관리 경량 모니터 프로세스 MMNL로 알 수 있다
CJQ0와 Jnnn 프로세스 : Job Queue
JOB_QUEUE_PROCESS 파라미터를 통해 조정할 수 있고 1000개까지 띄울 수 있다 j000~j999까지 이다 이 프로세스는 실체화 뷰(materialized view)를 재생하는 과정의 하나로 복제에 집중적으로 사용된다 그러나 스트림 기반으로 복제하는 경우에 job queue를 사용하는 대신에 AQ를 사용한다 개발자는 일회성(백그라운드)작업 또는 백그라운드에서 이메일을 보낸다든지 또는 백그라운드에서 장기간 걸리는 배치 프로세스를 처리하는 일 처럼 되풀이 되는 작업을 스케줄하기 위해 job queue를 자주 사용한다 백그라운드에서 작업을 함으로 써 참을성 없는 최종사용자에게 태스크에 걸리는 시간이 훨씬 덜 걸리는 것처럼 보이게 할 수 있다 이것은 LGWR과 DBWn이 함께 수행하는 이치와 유사하다 job queue 프로세스는 많은 작업을 백그라운드에서 수행하므로 이 프로세스가 모든 태스크를 완료하는 것을 기다릴 필요가 없다.
Jnnn 프로세스는 shared server와 매우 유사하지만 dedicated server와도 유사한 면이 있다 Jnnn 프로세스는 차례대로 작업을 처리하는 면에서는 공유되지만 dedicated server와 비슷하게 메모리를 관리한다(Jnnn 프로세스의 UGA 메모리는 PGA에 있다) 각 job queue 프로세스는 정확히 한 번에 한 작업씩 완료 시까지 차례대로 실행한다 그것이 동시에 여러 작업을 실행하려면 다수의 프로세스가 필요한 이유다 한 개의 작업을 멀티 쓰레드로 처리하는 일도 없으며 다른 작업을 선점하는 일도 없다 일단 작업을 실행하면 완료 할때까지 실행한다
Jnnn 프로세스는 시간에 따라 나타나고 사라지는데 1000개까지 설정하더라도 동시에 시작하지는 않는다 job queue 조정자(CJQ0)가 먼저 기동하고 job queue 테이블에서 수행할 필요가 있는 작업을 확인한 다음에 CJQ0가 Jnnn 프로세스를 시작할 것이다 Jnnn 프로세스는 작업을 완료하고 처리할 새로운 작업을 발견하지 못하면 빠져나가기 시작한다(사라진다)
QMNC와 Qnnn : AQ(진보된 큐)
이 둘의 관계는 CJQ0 프로세스와 작업 테이블의 관계와 같다 QMNC 프로세스는 CJQ0 프로세스가 작업 테이블을 감시하듯이 메시지가 가용한다는 dequeurs 메시지를 기다리면서 AQ와 경보(alters)를 감시한다 QMNC와 Qnnn은 또한 큐 전파(propagation)에 대한 책임을 지고 있다(데이터베이스에 존재하는 큐에 입력된 메시지를 다른 데이터베이스에 있는 큐로 옮기는 능력)
QMNC 프로세스는 수행할 필요가 있는 작업을 Qnnn 프로세스에 알려주면 Qnnn 프로세스는 그 작업을 처리한다 AQ_TM_PROCESSES 파라미터는 최대 10개의 이름을 가진 Qnnn 프로세스와 단일 QMNC 프로세스를 생성할 것인지를 결정한다 0으로 설정하면 존재하지 않을 것이다 job queue가 사용하는 Jnnn 프로세스와 같지 않게 Qnnn 프로세스는 지속적이다 10으로 설정하면 10개의 Qnnn 프로세스와 QMNC 프로세스를 데이터 베이스를 구동할 때와 인스턴스가 살아 있는 동안에 계속 보게 될 것이다
EMNC : 이벤트 모니터 프로세스
AQ 아키텍처의 일부분으로 큐 구독자(queue subscribers)에게 그들이 관심을 두고 있는 메시지를 공지한다 비동기적으로 수행되고 공지를 위한 콜백(callback)을 등록하기 위한 오라클 호출 인터페이스(OCI Oracle Call Interface) 함수가 있다 콜백은 관심 메시지가 큐에 도착할 때마다 자동으로 호출되는 OCI 프로그램에 등록된 함수다 EMNn은 가입자에게 공지하기 위해 사용된다 EMNC는 인스턴스가 시작된 후 첫 번째 공지가 발행되면 자동으로 시작된다 애플리케이션은 메시지를 조회하기 위해 명시적으로 message_receive(dequeuer)를 발행할 수 있다.
MMAN : 메모리 관리자
10g 이후 새롭게 선보였으며 자동으로 SGA 크기를 조절하는 기능을 위해 사용된다 MMAN 프로세스는 공유 메모리 컴포넌트(buffer / shared / java / large / streams)의 크기를 설정하거나 재조정
MMON, MMNL과 Mnnn : 관리모니터
AWR(automatic workload repository)에 통계 데이터를 수집하는데 사용된다 MMNL 프로세스는 스케줄링을 통해 SGA의 통계 데이터를 데이터베이스 테이블로 밀어 넣는다 MMON 프로세스는 데이터베이스 성능 이슈를 자동으로 탐지하고 새로운 자체 튜닝 기능 구현에 사용된다 Mnnn 프로세스는 job queue를 위한 Jnnn 또는 Qnnn 프로세스와 유사하다(MMON은 Mnnn 슬레이브 프로세스에 자신을 대표해서 작업 수행을 요청) Mnnn 프로세스는 본질적으로 일시적이며 필요한 만큼 나타났다 사라진다
CTWR : 변경 추적 프로세스
변경 추적 파일(3장)을 유지하는 책임
RVWR : 복구 Wrier
FLASHBACK DATABASE 명령어와 함께 사용되는 플래시 복구 영역(3장)에서 블록의 이전 이미지를 유지하는 책임
DMnn / DWnn : 데이터 펌프 마스터 / 작업자 프로세스
10gR1에서 추가된 기능이며 기존 exp/imp를 대체하도록 설계되었다 서버에서 실행되며 API는 PL/SQL을 거친다 데이터 펌프는 서버에서 실행되기 때문에 다양한 데이터 펌프 작업을 지원하는 기능이 추가되었다 데이터 펌프 마스터는 클라이언트 프로세스(API 입력을 받는 프로세스)로부터 데이터를 수집하고 실제 일을 수행하는 DWnn을 조정한다 DMnn 프로세스가 실제 메타 데이터와 데이터를 처리한다
슬레이브 프로세스
I/O 슬레이브
비동기 I/O를 지원하지 않는 시스템 또는 장치를 위해 대행한다 I/O 슬레이브를 사용해서 운영체제가 정상적으로 디스크 드라이브에 제공하는 것을 테이프 드라이브에 제공하도록 흉내낼 수 있다 실제 비동기 I/O를 하는 것 처럼 테이프 장치에 쓰는 일을 하는 I/O 슬레이브 프로세스는 다량의 데이터를 묶어서 쓸 수 있도록 건네준다 데이터를 성공적으로 쓰면 I/O슬레이브는 원 호출자에게 신호를 줘서 원 호출자는 기록할 필요가 있는 데이터 목록에서 이미 기록된 데이터 묶음을 제거한다
이런 방식으로 훨신 높은 처리량을 달성할 수 있는데 이것은 I/O 슬레이브가 느린 장치를 기다리는 동안 호출자는 다른 중요한 작업을 수행하면서 다음 쓰기를 위한 데이터를 얻을 수 있기 때문이다 오라클에서 I/O 슬레이브는 DBWn과 LGWR 그리고 RMAN에서 테이프에 쓰고자 할 때 I/O 슬레이브를 사용할 수 있다.
밑의 2개의 파라미터로 I/O 슬레이브를 제어할 수 있다
-BACKUP_TAPE_IO_SLAVES : RMAN이 테이프에 데이터를 백업, 복제 또는 복원하는데 I/O 슬레이브를 사용할지 말지를 결정한다 테이프를 고려해서 만들어졌고 이 장치는 특정 시점에 한 개의 프로세스만 액세스할 수 있으므로 파라미터의 데이터 타입은 물리적 장치의 수가 아니라 Boolean 타입이다 RMAN은 물리적 장치의 개수를 고려해서 필요한 만큼 슬레이브를 띄운다 TRUE일때는 한 개의 슬레이브 프로세스가 한 개의 테이브 장치에 데이터를 쓰거나 읽을 것이다 FALSE(default)면 사용할 수 없다 대신 백업 전용 서버 프로세스가 개입해서 테이프 장치를 액세스할 것이다
-DBWR_IO_SLAVES : DBW0프로세스가 사용하는 I/O 슬레이브의 개수를 지정한다 버퍼 캐시의 ditry 블록을 디스크로 쓰는 작업을 수행하고 디폴트 값은 0이고 I/O 슬레이브는 사용되지 않는다 0보다 큰 값으로 설정하면 LGWR과 ARCH 또한 최대 4개까지 I/O 슬레이브를 사용할 수 있다
DBWR I/O 슬레이브는 I1nn이란 이름으로 LGWR I/O 슬레이브는 I2nn이란 이름으로 나타난다
Pnnn : 병렬 쿼리 실행 서버
SELECT, CREATE TABLE, CREATE INDEX, UPDATE와 같은 SQL 문을
받아서 동시에 처리할 수 있는 여러 개의 실행계획으로 구성된 단일 실행계획을 만든다 각 실행계획의 결과는 한 개의 큰 결과로 합쳐진다 순차적으로
실행한 경우보다는 적은 시간 내에 작업을 수행하기 위해서다 예를 들어 10개의 파일에 걸쳐 저장된 대용량
테이블이 존재한다면 마음대로 쓸 수 있는 CPU는 16개가
있고 이 테이블에 ad-hoc 쿼리를 실행할 필요가 있다 단지 한 개의 프로세스가 모든 데이터를 순차적으로
읽고 처리하는 것 보다는 실행계획을 32개 조각으로 분해하여 해당 장비를 제대로 사용하는 것이 더 유리하다
병렬 쿼리를 사용할 때 Pnnn이란 이름을 가진 프로세스를 볼 수 있는데( 이 프로세스들이 병렬 쿼리 실행 서버 자체) 병렬 문장을 처리하는 동안 서버프로세스는 병렬 쿼리 코디네이터(Parallel Query Coordinator)역할을 수행 병렬 쿼리에 관한 문서에서 조정자 프로세스에 대한 참고문헌을 보면 조정자는 단순히 사용자의 요청을 처리하는 서버 프로세스를 의미
'스터디북' 카테고리의 다른 글
| [09/30] Admin 1 C 16 Admin 2 C 1 (0) | 2015.09.30 |
|---|---|
| [09/23] Expert Oracle Database 16장 데이터 암호화 (0) | 2015.09.23 |
| [09/09] admin 4일차 실습 (0) | 2015.09.10 |
| [09/08] admin 3일차 실습 (0) | 2015.09.09 |
| [09/07] admin 2일차 실습 및 발표 정리 (0) | 2015.09.09 |
