☞Reducing Contention for Dispatcher Processes 
●  dispatcher process에 대한 contention을 정의하는 방법
●  dispatcher process를 추가하는 방법



♣ Identifying Contention for Dispatcher Processes
▶  dispatcher processes에 대한 contention은 아래의 징후에 의해서 알게된다.
· dispatcher의 높은 사용율
· dispatcher가 응답큐(Response Queue)의 회답을 기다리는 시간의 계속적인 증가.

●  Examing Busy Rates for Dispatcher Processes
▶  Dispatcher process의 행동에 대한 statistics는 동적 performance table V$DISPATCHER에 나타난다.
▶  이 테이블은 SYS 유저와 SYSTEM와 같은 SELECT ANY TABLE 시스템 권한을 가진 다른 유저들만이 사용할 수 있다.
· IDLE : 이 칼럼은 dispatcher process를 위한 idle time을 백분의 몇초로서 보여준다.
· BUSY : 이 칼럼은 dispatcher process를 위한 busy time을 백분의 몇초로서 보여준다.
·SELECT network "Protocol", SUM(busy) / ( SUM(busy) + SUM(idle) ) "Total Busy Rate"
              FROM v$dispatcher
              GROUP BY network;
▶  이 질의는 각 프로토콜의 dispatcher process를 위한 총 busy rate를 반환
▶  결과는
Protocol Total Busy Rate
------------------  -------------------------- 
DECnet  .004589828 
TCP  .029111042 
▶  이 결과로부터 아래와 같은 몇개의 견해를 만들 수 있다.
· DECnet dispatcher process는 거의 시간당 0.5%씩 바쁘다.
· TCP dispatcher process는 거의 시간당 3%씩 바쁘다.
▶  만약 특별한 프로토콜의 dispathcher process가 시간당 50%이상씩 바쁘게 되면, dispatcher process를 증가시킴으로서 성능향상에 좋을 수 있다.
●  Examining Wait Times for Dispatcher Process Response Queues
▶  Dispatcher process를 위한 응답 큐의 행동을 반영하는 statistics는 동적인 performance table인 V$QUEUE에 쓰여진다.
▶  SYS 유저와 SYSTEM와 같은 SELECT ANY TABLE 시스템 권한을 가진 다른 유저들만이 사용
▶  이 칼럼은 큐에 응답을 위한 wait time을 보여준다.
·WAIT : 이 칼럼은 큐에 존재하는 모든 응답들을 위한 총 wait time을 백분의 몇초로서 보여준다.
·TOTALQ이 칼럼은 큐에 존재한 적이 있는 응답의 총 수를 보여준다.
·SELECT network "Protocol",
              DECODE( SUM(totalq), 0 ,'NO RESPONSES',
              SUM(wait)/SUM(totalq) || 'hundredths of seconds ')
              "Average Wait Time per Response"
              FROM v$queue q, v$dispatcher d
              WHERE q.type = 'DISPATCHER' AND q.paddr = d.paddr GROUP BY network ;

▶  이 질의는 백분의 일초 당 각 dispatcher process에 있는 응답 큐에서 user process에 응답을 전달하기 위해 하나의 응답이 기다리는 평균시간을 반환한다.
▶  이 질의는 network protocol에 의해 V$QUEUE 테이블의 행들을 그룹화한 V$DISPATCHER 테이블을 사용한다.
▶  이 질의는 또한 큐에 어떠한 응답도 없을 경우를 위해서 프로토콜을 알아볼수 있는 DECODE syntax를 사용한다.
▶  결과는
Protocol Average Wait Time per Response
------------------  -------------------------- 
DECnet  .1739130 hundredths of seconds 
TCP  No Response 
▶  이 결과로부터, 큐에 있는 하나의 응답은 DECnet dispatcher process에서는 평균적으로 천분의 0.17초 만큼 기다리고, TCP dispatcher process에서는 queue에 어떤 응답도 가지지 않는다는 것을 알수 있다.
▶  특별한 네트워크 프로토콜을 위한 평균 wait time이 application이 동작중일 때 고정적으로 계속 증가된다면, dispatcher process를 추가시킴으로서 성능을 향상시킬 수 있울 것이다.



♣ Adding Dispatcher Processes
▶  오라클이 ALTER SYSTEM 명령의 MTS_DISPATCHER parameter를 runing하는 동안에 dispatcher process를 추가할 수 있다.
▶  dispatcher process의 총 수는 초기화 parameter인 MTS_MAX_DISPATCHERS의 값에 의해 한계가 결정된다.
▶  dispatcher process를 추가하기 전에 이 값을 증가시키는 것이 필요
▶  이 parameter의 default 값이 5이고 최대 값은 operating system에 따라 변화시킬 수 있다.



☞Reducing Contention for Shared Server Porcesses
●  shared server process에 대한 contention을 정의하는 방법
●  shared server process의 최대수를 증가시키는 방법



♣ Identifying Contention for Shared Server Processes
▶  shared server process에 대한 Contention은 request query에 있는 request를 위해 기다리는 시간이 계속적으로 증가함으로 나타난다.
▶  shared server process를위한 request 큐의 행동을 반영하는 statistics는 동적 performance table인 V$QUEUE에 나타난다.
▶  SYS 유저 와 SYSTEM와 같은 SELECT ANY TABLE 시스템 권한을 가진 다른 유저들만이 사용할 수 있다.
▶  이 칼럼은 큐에 응답을 위한 wait time을 보여준다. 이들 칼럼은 큐에 있는 request들을 위한 wait time을 보여준다.
·WAIT :이 칼럼은 큐에 존재했던 적이 있는 모든 request들을 위한 총 waiting time을 백분의 몇초로 나타낸다.
·BUSY : 이 칼럼은 큐에 존재한 적이 있는 request의 총수를 보여준다.
·SELECT DECODE (totalq, 0, 'NO Requests', wait/totalq || 'hundredths of seconds')
              "Average Wait Time Per Requests"
              FROM v$queue
              WHERE type = 'COMMON' ;
▶ 이 질의는 request queue에 대한 request의 총수와 모든 requests에 대한 총 wait time을 반환
▶ 결과는
Average Wait Time Per Request
-------------------------------------------- 
.090909 hundredths of seconds 
▶ 위 결과로부터 한 request는 그것이 처리되기전에 큐에서 평균 백분의 0.09초를 기다린다는 것을 알 수 있다.
▶ 아래의 질의를 통해서 얼마나 많은 shared server process가 동시에 동작하는지를 결정할 수 있다.
·SELECT COUNT(*) "Shared Server Processes"
              FROM v$shared_servers
              WHERE status != 'QUIT';

▶ 결과는
Shared Server Processes
-------------------------------------------- 
10 



♣ Adding Shared Server Processes
▶  존재하는 shared server process에 대한 load가 증가하면 오라클은 자동적으로 shared server process를 증가시키는데, 명시적으로 shared server process를 더 많이 추가시켜 단순하게 성능을 향상시키는 것을 좋지 않다.
▶  그러나 shared server process의 수가 초기 parameter MTS_MAX_SERVERS에 의해 설정된 한계치에 달하고 request 큐에 있는 평균 wait time이 여전히 증가하고 있다면 MTS_MAX_SERVERS값을 증가시킴으로 성능을 향상시킬 수 있다.
▶ 이 parameter의 default값은 20이고 최대값은 operating system에 따라 변할 수 있다.
▶ 오라클이 자동적으로 shared server process를 증가하거나 명시적으로 아래 방법중 하나를 통해서 shared process를 증가시킬수 있다.
·초기 parameter인 MTS_SERVERS
·ALTER SYSTEM 명령의 MTS_SERVERS parameter