######  What are the major tuning areas in database performance tuning  #######

  - Memory - shared pool, large pool, buffer cache, redo log buffer, and sort area size.
  - I/O - distributing I/O, striping, multiple DBWn processes, and DBWn I/O slaves.
  - CPU - CPU utilization.
  - Space management - extent allocation and Oracle block efficiency.
  - Redo log and checkpoint - redo log file configuration, redo entries, and checkpoint.
  - Rollback segment - sizing rollback segments.
  - Network

###### 조정해야할 메모리 영역
전체 SGA 영역 : 2.4G
shared_pool_size = ???
large_pool_size = ???
java_pool_size = ???
db_cache_size = ???
SHARED_POOL_RESERVED_SIZE=???

 

##################################################
### PGA 성능(할당량) 조정
##################################################
PGA target advice => v$pga_target_advice를 이용하여 적당 할당량을 조사한다.

-- PGA 어드바이스
select round(pga_target_for_estimate/1024/1024) as target_size_MB,
bytes_processed,estd_extra_bytes_rw as est_rw_extra_bytes,
estd_pga_cache_hit_percentage as est_hit_pct,
estd_overalloc_count as est_overalloc
from v$pga_target_advice;

=>위의 쿼리를 실행해서 최적의 PGA할당량을 찾아낸다

PGA Memory Advisory  DB/Inst: KMSMESV1/KMSMESV1  End Snap: 886
-> When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value
   where Estd PGA Overalloc Count is 0

                                       Estd Extra    Estd PGA   Estd PGA
PGA Target    Size           W/A MB   W/A MB Read/      Cache  Overalloc
  Est (MB)   Factr        Processed Written to Disk     Hit %      Count
---------- ------- ---------------- ---------------- -------- ----------
        94     0.1        326,688.8         11,869.3     96.0      2,140
       188     0.3        326,688.8         11,869.3     96.0      2,139
       375     0.5        326,688.8          2,393.2     99.0        646
       563     0.8        326,688.8            110.8    100.0          0
       750     1.0        326,688.8            110.8    100.0          0
       900     1.2        326,688.8            110.8    100.0          0
     1,050     1.4        326,688.8            110.8    100.0          0
     1,200     1.6        326,688.8            110.8    100.0          0
     1,350     1.8        326,688.8            110.8    100.0          0
     1,500     2.0        326,688.8            110.8    100.0          0
     2,250     3.0        326,688.8            110.8    100.0          0
     3,000     4.0        326,688.8            110.8    100.0          0
     4,500     6.0        326,688.8            110.8    100.0          0
     6,000     8.0        326,688.8            110.8    100.0          0
          -------------------------------------------------------------

:::::::::::::::::::::::         결과          ::::::::::::::::::::::::::::::
=========> PGA 사이즈 조정 : 현재 사이즈 적정 

##################################################
### SGA 크기 조정
##################################################

SGA Target Advisory  DB/Inst: KMSMESV1/KMSMESV1  End Snap: 886

SGA Target SGA Size   Est DB      Est DB   Est Physical
  Size (M)   Factor Time (s) Time Factor          Reads
---------- -------- -------- ----------- --------------
       752       .5   78,897         1.0      5,109,138
     1,128       .8   78,044         1.0      4,873,605
     1,504      1.0   77,494         1.0      4,723,249
     1,880      1.3   77,293         1.0      4,667,665
     2,256      1.5   77,238         1.0      4,653,967
     2,632      1.8   77,238         1.0      4,653,967
     3,008      2.0   77,239         1.0      4,653,967
-------------------------------------------------------------

:::::::::::::::::::::::         결과          ::::::::::::::::::::::::::::::
=========> SGA 사이즈 조정 : 1.5GB -> 2.5GB로 사이즈 조정 
★★★★ statspack분석 결과에 의해  SGA_TARGET 파라메타 2.5GB로 재조정.
alter system set SGA_MAX_SIZE=(2.5GB)

##################################################
### shared pool 성능(할당량) 조정
##################################################

1.먼저 현재 사용중인 데이타베이스에 대해 라이브러리 캐시영역에 대한 크기가 적정한지 조사한다.

select namespace,gets,gethits,gethitratio
from v$librarycache
where namespace = 'SQL AREA';

=> 참조 : 만약 gethitratio 컬럼의 값이 90%이상이라면 라이브러리 캐쉬영역이 개발자들의 SQL 파싱정보를 저장하기에 충분한 메모리 공간을
          확보하고 있음을 의미하며 만약 90% 이하라면 성능이 저하 될 수도 있다는 것을 의마한다.

=> Quality DB의 경우 다음과 같은 결과가 나옴.
NAMESPACE             GETS    GETHITS GETHITRATIO
--------------- ---------- ---------- -----------
SQL AREA            885978     878552  .991618302
=========> 99%

## 부가적으로 pins에 대한 reloads의 비율을 확인한다.

select sum(pins),sum(reloads),sum(reloads) / sum(pins)
from v$librarycache
where namespace = 'SQL AREA';

=> 완성차 DB의 경우 다음과 같이 나옴.
 SUM(PINS) SUM(RELOADS) SUM(RELOADS)/SUM(PINS)
---------- ------------ ----------------------
  85931701          506             5.8884E-06

========> 참조 : PINS에 대한 reloads에 대한 비율이 1%미만일 경우 라이브러리 캐쉬 영역의 크기가 SQL 파싱정보를
                 저장하기에 충분하다는 의미이다.

 

현재 할당된 shared_pool 사이즈를 조사한다.
select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;

=> 완성차 DB의 경우 다음과 같이 나옴.
POOL             MBYTES
------------ ----------
             863.996956
shared pool  511.985039
streams pool 48.0495529
large pool           32
java pool            64

2. Shared pool advice => v$shared_pool_advice 를 이용해서 oracle의 사이즈 advice를 조사한다.

SELECT shared_pool_size_for_estimate "Size of Shared Pool in MB",
       shared_pool_size_factor "Size Factor",estd_lc_time_saved "Time Saved in sec"
  FROM v$shared_pool_advice;

Shared Pool Advisory  DB/Inst: KMSMESV1/KMSMESV1  End Snap: 886
-> SP: Shared Pool     Est LC: Estimated Library Cache   Factr: Factor
-> Note there is often a 1:Many correlation between a single logical object
   in the Library Cache, and the physical number of memory objects associated
   with it.  Therefore comparing the number of Lib Cache objects (e.g. in
   v$librarycache), with the number of Lib Cache Memory Objects is invalid

                                        Est LC Est LC  Est LC Est LC
    Shared    SP   Est LC                 Time   Time    Load   Load      Est LC
      Pool  Size     Size       Est LC   Saved  Saved    Time   Time         Mem
  Size (M) Factr      (M)      Mem Obj     (s)  Factr     (s)  Factr    Obj Hits
---------- ----- -------- ------------ ------- ------ ------- ------ -----------
       256    .5       72        4,370 #######    1.0  33,605    1.4  32,095,562
       320    .6      132        7,162 #######    1.0  28,485    1.2  32,102,312
       384    .8      195       12,092 #######    1.0  24,534    1.0  32,102,864
       448    .9      204       13,130 #######    1.0  24,534    1.0  32,102,864
       512   1.0      204       13,130 #######    1.0  24,534    1.0  32,102,864
       576   1.1      204       13,130 #######    1.0  24,534    1.0  32,102,864
       640   1.3      204       13,130 #######    1.0  24,534    1.0  32,102,864
       704   1.4      204       13,130 #######    1.0  24,534    1.0  32,102,864
       768   1.5      204       13,130 #######    1.0  24,534    1.0  32,102,864
       832   1.6      204       13,130 #######    1.0  24,534    1.0  32,102,864
       896   1.8      204       13,130 #######    1.0  24,534    1.0  32,102,864
       960   1.9      204       13,130 #######    1.0  24,534    1.0  32,102,864
     1,024   2.0      204       13,130 #######    1.0  24,534    1.0  32,102,864
          -------------------------------------------------------------+ The above output shows the current setting of the shared pool is
  512M (for which Size factor is 1).

+ It also shows decreasing the size of the shared pool to the 50% of its
  current value will also be equally efficient as the current value.
+ Also doubling the size of the shared pool will save extra 2300 sec in parsing.
+ Using this view a DBA has the correct picture to design Shared pool.

========> 결론 : 현재 PEMS DB의 shared_pool 사이즈를 init*.ora 파일에서 늘려준다.
shared_pool_size = 800M(????)

 

### 현재 SGA에 대한 할당 조사
select current_size from v$buffer_pool;
select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;

3. SHARED_POOL_RESERVED_SIZE에 대한 성능 조절

=> SHARED_POOL_RESERVED_SIZE는 PL/SQL 블록으로 실행된 sql문의 구문분석 정보를 저장할때 사용되는 공유 풀 영역의 크기를
   지정하는 파라메타이다
=> 기본값은 SHARED_POOL_SIZE의 10%이며 최대값은 SHARED_POOL_SIZE 값의 1/2 이다.
=> v$shared_pool_reserved 자료사전의 REQUEST_FAILURES의 컬럼값이 0이 아니거나 계속 증가값을 보일때 이파라메타 값을
   크게 해준다.

select request_failures from v$shared_pool_reserved;

REQUEST_FAILURES
----------------
               0

========> 결론 :SHARED_POOL_RESERVED_SIZE 변경 없음
SHARED_POOL_RESERVED_SIZE = 25M(?????)

##################################################
#### DB Cache Size 성능 조정
##################################################

1. DB cache advice => v$db_cache_advice 동적 성능 뷰를 이용하여 db cache 사이즈를 시뮬레이션 해본다.

column size_for_estimate         format 999,999,999,999 heading 'Cache Size (m)'
column buffers_for_estimate      format 999,999,999 heading 'Buffers'
column estd_physical_read_factor format 999.90 heading 'Estd Phys|Read Factor'
column estd_physical_reads       format 999,999,999 heading 'Estd Phys| Reads'

SELECT size_for_estimate, buffers_for_estimate,estd_physical_read_factor, estd_physical_reads
  FROM V$DB_CACHE_ADVICE
 WHERE name = 'DEFAULT'
   AND block_size    = (SELECT value FROM V$PARAMETER
                         WHERE name = 'db_block_size')
   AND advice_status = 'ON';

    Size for  Size      Buffers   Read     Phys Reads     Est Phys % dbtime
P    Est (M) Factr  (thousands)  Factr    (thousands)    Read Time  for Rds
--- -------- ----- ------------ ------ -------------- ------------ --------
D         80    .1           10    2.1          9,703       21,737     28.0
D        160    .2           20    1.1          5,315        5,540      7.1
D        240    .3           30    1.1          5,029        4,485      5.8
D        320    .4           40    1.0          4,948        4,186      5.4
D        400    .5           50    1.0          4,897        4,001      5.2
D        480    .6           59    1.0          4,862        3,869      5.0
D        560    .6           69    1.0          4,829        3,750      4.8
D        640    .7           79    1.0          4,796        3,628      4.7
D        720    .8           89    1.0          4,761        3,497      4.5
D        800    .9           99    1.0          4,740        3,419      4.4
D        864   1.0          107    1.0          4,723        3,359      4.3
D        880   1.0          109    1.0          4,709        3,306      4.3
D        960   1.1          119    1.0          4,668        3,152      4.1
D      1,040   1.2          129    1.0          4,649        3,083      4.0
D      1,120   1.3          139    1.0          4,621        2,979      3.8
D      1,200   1.4          149    1.0          4,607        2,929      3.8
D      1,280   1.5          159    1.0          4,599        2,899      3.7
D      1,360   1.6          169    1.0          4,594        2,882      3.7
D      1,440   1.7          178    1.0          4,594        2,880      3.7
D      1,520   1.8          188    1.0          4,592        2,875      3.7
D      1,600   1.9          198    1.0          4,580        2,829      3.7
          -------------------------------------------------------------

========> 결론 : 현재 PEMS DB의 db_cache 사이즈를 1.6GB로 변경
db_cache_size = 1.6GB(???)

##################################################
#### Redo buffer Size 성능 조정
##################################################

Check the statistic redo buffer allocation retries in the V$SYSSTAT view.
If this value is high relative to redo blocks written, try to increase the LOG_BUFFER size.
 
Query for the same is
 
select * from v$sysstat where name like 'redo buffer allocation retries'
or
select * from v$sysstat where name like 'redo blocks written';

혹은 v$sysstat 자료사전에서 서버 프로세스가 로그 정보를 저장했던 로그버퍼의 블록 수(REDO ENTRIES)와 로그버퍼의 경합으로
인해 발생한 대기상태에서 다시 로그 버퍼공간을 할당 받았던 불록 수(redo buffer allocation entries)를 확인한다.

=>이 SQL문에 의한 실행 결과
select name,value
from v$sysstat
where name in ('redo buffer allocation retries','redo entries');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
redo entries                                                       23465374
redo buffer allocation retries                                           91=>0일 수록 좋은것

========> 결론 : 현재 quality DB의 log_buffer 사이즈를 14MB * 2 이상으로 init*.ora 파일에서 늘려준다.
log_buffer = 30M  
       
##################################################
#### java_pool Size 성능 조정
##################################################

** Java Pool advice => v$java_pool_advice

select JAVA_POOL_SIZE_FOR_ESTIMATE,JAVA_POOL_SIZE_FACTOR,ESTD_LC_LOAD_TIME
from v$java_pool_advice

JAVA_POOL_SIZE_FOR_ESTIMATE JAVA_POOL_SIZE_FACTOR ESTD_LC_LOAD_TIME
--------------------------- --------------------- -----------------
                          4                     1              9493
                          8                     2              9493

========> 결론 : 현재 PEMS DB의 java_pool_size 사이즈를 8MB 이상으로 init*.ora 파일에서 늘려준다.
java_pool_size=128M(20971520)

##################################################
#### Redo-log file  Size 성능 조정
##################################################
FAST_START_MTTR_TARGET='숫자값'으로 설정한다(V$MTTR_TARGET_ADVICE)
alter system set FAST_START_MTTR_TARGET=300

SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR,
    OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES  from v$instance_recovery;

ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE
---------------- ---------------- ----------- -------------- --------------------
          942            18432          71             59                     49     
388462

The recommended optimal redolog file size is 49 MB as seen from column -OPTIMAL_LOGFILE_SIZE.
This is as per the setting of "fast_start_mttr_target" = 170

각 리두로그 사이즈 600M로 조정

$@# !! SQL 튜닝 전에

SQL>alter session set timed_statistics=true;
SQL>alter session set sql_trace=true;
요거 켜주기......

### REDO LOG 파일 재배치 해야함.(물리적으로 서로 다른 디스크 경로에 변경 배치한다)

ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE ADD LOGFILE GROUP 1 ('/ora_log/KMSMESV1/rdo1/redo01a.log','/ora_dump/KMSMESV1/rdo2/redo01b.log') SIZE 500M

ALTER DATABASE DROP LOGFILE GROUP 2;
ALTER DATABASE ADD LOGFILE GROUP 2 ('/ora_log/KMSMESV1/rdo1/redo02a.log','/ora_dump/KMSMESV1/rdo2/redo02b.log') SIZE 500M

ALTER DATABASE DROP LOGFILE GROUP 3;
ALTER DATABASE ADD LOGFILE GROUP 3 ('/ora_log/KMSMESV1/rdo1/redo03a.log','/ora_dump/KMSMESV1/rdo2/redo03b.log') SIZE 500M

ALTER DATABASE DROP LOGFILE GROUP 4;
ALTER DATABASE ADD LOGFILE GROUP 4 ('/ora_log/KMSMESV1/rdo1/redo04a.log','/ora_dump/KMSMESV1/rdo2/redo04b.log') SIZE 500M

ALTER DATABASE DROP LOGFILE GROUP 5;
ALTER DATABASE ADD LOGFILE GROUP 5 ('/ora_log/KMSMESV1/rdo1/redo05a.log','/ora_dump/KMSMESV1/rdo2/redo05b.log') SIZE 500M

ALTER DATABASE DROP LOGFILE GROUP 6;
ALTER DATABASE ADD LOGFILE GROUP 6 ('/ora_log/KMSMESV1/rdo1/redo06a.log','/ora_dump/KMSMESV1/rdo2/redo06b.log') SIZE 500M

### ADDITIONAL 1 : Disk I/O 튜닝

select tablespace_name,file_name,phyrds, phywrts
from dba_data_files df,v$filestat fs
where df.file_id = fs.file#;

===============> 결론 : 쿼리 결과 system 테이블 스페이스와 undo table space를 분리해야함. 
1.DB SHUTDOWN

2.undo datafile 이동 ex)F:\->H:\
 =>이동 후 기존 datafile 삭제 
3.db startup(mount까지)

alter database rename file 'E:\ora_data1\KMSMESP1\UNDOTBS01.DBF' to 'H:\ora_data4\KMSMESP1\undo_data\UNDOTBS01.DBF';
alter database rename file 'E:\ora_data1\KMSMESP1\UNDOTBS02.DBF' to 'H:\ora_data4\KMSMESP1\undo_data\UNDOTBS02.DBF';
alter database rename file 'E:\ora_data1\KMSMESP1\UNDOTBS03.DBF' to 'H:\ora_data4\KMSMESP1\undo_data\UNDOTBS03.DBF';

4.DB OPEN  

##### redolog 변경 샘플

ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE ADD LOGFILE GROUP 1 ('I:\ora_log\KMSMESQ1\rdo1\REDO01A.LOG', 'H:\ora_dump\KMSMESQ1\rdo2\REDO01B.LOG') SIZE 200M;

ALTER DATABASE DROP LOGFILE GROUP 2;
ALTER DATABASE ADD LOGFILE GROUP 2 ('I:\ora_log\KMSMESQ1\rdo1\REDO02A.LOG', 'H:\ora_dump\KMSMESQ1\rdo2\REDO02B.LOG') SIZE 200M;

ALTER DATABASE DROP LOGFILE GROUP 3;
ALTER DATABASE ADD LOGFILE GROUP 3 ('I:\ora_log\KMSMESQ1\rdo1\REDO03A.LOG', 'H:\ora_dump\KMSMESQ1\rdo2\REDO03B.LOG') SIZE 200M;

8. Oracle Shared Server 튜닝

- 목표
  > Oracle Shared Server 환경에서의 유저 관리 문제 식별
  > 성능 최적화를 위한 Oracle Shared Server 환경 구성
  > Oracle Shared Server 프로세스를 사용하여 성능 문제 진단 및 해결
 
- 디스패처 모니터 
  > 서버가 디스패처를 자동으로 시작하거나 정지하지 않기 때문에 디스패처 사용률을 모니터해야 한다.
  > v$shared_server_monitor
    >> 연결 및 세션 제한과 세션의 현재 사용현황을 확인할 수 있다. 
    >> sessions 가 디스패처에 대한 실제 제한보다 적게 설정되어 있으면 sessions 파라미터 값이 기본적으로 maximum_connections 의 값으로 설정된다.
  > v$dispatcher
    >> 디스패처 경합 식별
       select network Protocol, status,
              sum(owned) Client,
              sum(busy) * 100 / (sum(busy) + sum(idle)) Busy_Rate
       from v$dispatcher
       group by network, status;
  > 디스패처의 사용률이 50%를 넘으면 디스패처 수의 증가 고려
    유저는 해당 세션이 끝날 때까지 동일한 디스패처에 바인드 되므로 새로 연결할 경우에만 새 디스패처를 사용할 수 있다.
    ALTER SYSTEM SET dispatchers = 'protocol, number';
  > 유저 세션 대기 여부 조회, 평균 대기 시간은 1/100 초 단위로 나타난다.
    select decode(sum(totalq), 0, 'No Responses', sum(wait) / sum(totalq)) avg_wait_time
    from v$queue q, v$dispatcher d
    where q.type = 'DISPATCHER'
      and q.paddr = d.paddr;  
  > v$dispatcher_rate
      
- Shared Server 모니터
  > max_shared_servers 값이 현재 사용 가능한 서버 수보다 높으면 기존의 Shared Server 가 사용되고 있을 때 PMON 백그라운드 프로세스가 Oracle Shared Server 프로세스를 동적으로 시작한다.
    그리고, Shared Server 가 Idle 상태에 있을 때 Shared Server 수가 shared_servers 에 도달할 때까지 PMON 이 Shared Server 를 제거한다.
    다음 명령을 사용하여 Shared Server 를 추가하거나 제거한다.
    ALTER SYSTEM SET SHARED_SERVERS = number;
  > v$shared_server
    select name, requests,
           busy * 100 / (busy + idle), status
    from v$shared_server
    where status != 'QUIT';
  > v$queue
    select decode(totalq, 0, 'No Requests', wait/totalq || 'hundredths of seconds')
    from v$queue
    where type = 'COMMON';    
   
- 문제 해결
  > Shared Server 를 사용하면 startup 및 shutdown 과 같은 권한이 필요한 작업을 수행할 수 없다. 이 경우 Dedicated Server 를 사용해야 한다.
  > 배치 작업 등 사용률이 많은 작업은 Dedicated Server 를 사용해야 한다.   
 
- 관련 Dictionary
  > v$circuit : 데이터베이스에 대한 유저 연결 정보
  > v$dispatcher : 디스패처 프로세스에 대한 정보
  > v$dispatcher_rate : 디스패처 프로세스에 대한 비율 통계
  > v$queue : 다중 스레드 메시지 큐에 대한 정보
  > v$shared_server_monitor : Shared Server 연결을 튜닝하는데 유용한 정보
  > v$shared_server : Shared Server 프로세스에 대한 정보
  > select d.network, d.name disp, s.username oracle_user, s.sid, s.serial#,
           p.username os_user, p.terminal, s.program
    from v$dispatcher d, v$circuit c, v$session s, v$process p
    where d.paddr = c.dispatcher(+)
      and c.saddr = s.saddr(+)
      and s.paddr = p.addr(+)
    order by d.network, d.name, s.username;
    

ORACLE - Shared Server와 Dedicated Server의 접속 방식

---

 

 

• 이전에 봤던 그림이랑 다르네요. ㅡ.,ㅡ 물론, 데이터베이스 버퍼 캐시 등도 있지만,
• 설명을 하기 편하게 하기 위해, 생략 하였습니다.

• 사용자 프로세스가 Dedicated Server를 통해 접속

 

• 반면 Shared Server를 통하면 여러개의 백그라운드 프로세스를 통하여 접속 및 처리가 가능하게 됩니다.
• DO0 , DO1...은 디스패쳐입니다.
• Conn hr/hr 이 L에 돌아갔다가 오는데, 이것은 리다이렉트 방식입니다.

• 이렇게 프로세스는 적지만 다량의 작업이 가능하기 때문에, 서버에 부하가 적습니다.
• 하지만, 반환하는 시간이 Dedicated Server 보다는 조금 더 오래 걸릴 수 있습니다.
• Shared Server를 사용한다고 해서, Dedicated Server를 사용하지 못하는 것은 아닙니다.
  • Shared Server를 사용하면, 서버 프로세스들간의 Road Balance가 되어서 idle(논다)프로세스가 줄어들어서 작업에 효율을 높일 수 있습니다.

PPT 참고 설명

---

• Dedicated Server

  

  • 클라이언트가 명령문을 요청해서 처리하는 동안에만 동작하는 프로세스 입니다.

 

• Shared Server

  
  
  

  

  • 미리 정의된 프로세스들이 사용자의 접속이 없어도 이렇게 실행되어 있습니다.
  • 사용자는 Dispatcher 들을 통해서 간접적으로 접속하여 반환하게 됩니다.
    

---

# 기타 설명

• Dedicated Server에서는 공유할 필요가 없기 때문에, 각각의 명령문을 PGA에 저장되어 사용됩니다.
• 반면, Shared Server Processor 들도 PGA가 있긴 하지만, 각각의 명령문을 공유해야 하기 때문에 Stack정보를 제외하고 나머지는 SGA에 들어가면서 UGA로 명칭만 변경되어 공유가 됩니다.
• 이 UGA 는 기본적으로 Shared Pool에 들어가게 되고, 접속자가 늘어날 경우에는 이 UGA공간도 늘어납니다.
• Shared Server 구조에서는 Large Pool 사이즈를 지정하여, UGA가 들어갈 수 있도록 사용해줘야 합니다.(기본 0)
  • Shared Server 구조는 다중 시스템(프로세스가 여러개)일 때 효율적입니다.
• Shared Server를 구성할 때에는 Spfile Shared_Servers = 를 몇개이다 라고 지정해야 하며,
• Dispatchers = 역시 속성등도 구성을 해줘야 합니다.
  • 그 중에, Connection 개수를 지정해 주는데, 예로 Conn = 30 이면, 최대 90명이 접속가능 합니다.
  • 또한 Pool = on 속성을 사용할 수 있으며, 이것을 사용하면 세션 기능도 사용가능하여 Connection을 더 증가시킬 수 있습니다.
    • 예 : Dispatchers = (conn = 30)
                                (Pool = on)
                                (sess = 50)
    • 풀링기능을 활성화 시킴으로써 더 많은 사용자들을 수용할 수 있습니다.
  • Connection Manager 라는 미들티어를 구성할 수 있는데, 이것은 별도의 기기에 구성하여 서버로 사용해야 합니다.
  • 사용자는 이 미들티어를 통해서 접속하며, 미들티어는 사용자의 다중접속을 서버에게는 단일 접속으로 처리하도록 해줍니다.

    

  • ▲오라클 Connection Manager

---

 Oracle Shared Server의 이점

• Instance에 대한 Process 수를 줄인다.
• 허용되는 User수를 증가시킨다.
• 로드 밸런싱을 수행한다.
  • 서버프로세스의 로드밸런스
• 휴지 Server Process의 수를 줄인다.
• 메모리 사용량과 시스템 오버헤드를 줄인다.
  • 주로 메모리에 대한 오버헤드는 많이 줄어들지만, CPU에 대한 오버헤드는 증가합니다.

 

 Oracle Shared Server와 함께 Dedicated Server 사용

---

 

절차상의 차이점은 있지만, 둘다 리스너를 통해서 가야합니다.

또한 항상 디스패쳐당 접속수가 동일하게 유지하도록 해야 합니다.

이렇게 디스패쳐에 연결되기 위해서는 Remote와 Server의 접속방식이 동일해야 합니다.

SYSDBA가 접속할 때는 LOCAL 이던 무엇이던간에 무조건 전용서버가 할당됩니다.

• 사용자는 Request Queue를 통해 간접적으로 전하고, 반환을 받습니다.
• Response Queue는 Dispatcher당 하나씩 가지고 있습니다.

• Shared Pool 및 다른 메모리구조 : Larger Pool 입니다. Large Pool은 이러한 문제로 인해 반드시 설정해야 합니다.

---

Oracle Shared Server의 구성

• 필수 초기화 Parameter
  • DISPATCHERS
  • SHARED_SERVERS
    • 똑똑합니다. 동적으로 MAX 값까지 필요하면 늘여줍니다. 하지만, 줄이는건 동적이지 못합니다.
      
• 선택적 초기화 Parameter
  • MAX_DISPATCHERS
  • MAX_SHARED_SERVERS
    • 이 MAX 값은 Default값이 있기 때문에 선택적 값입니다.
  • CIRCUITS
    • Shared Server를 통한 경로. Response, Request를 통한....
    • 이것은 값을 튜닝해서 서버의 성능을 높이거나 하진 않지만, 값을 높여 놓으면 나중에 오라클이 인지를 하게 되고, 나중에 오라클이 Queue 사이즈를 크게 조정하거나 합니다.
    • 단, 큐를 키우게 되면 SGA의 다른 요소가 영향을 받습니다.
  • SHARED_SERVER_SESSIONS
    • Shared Server Sessions 을 모두 제한하는 파라미터 입니다.
    • 만약, 6개의 세션이 등록되었다면, 6개의 세션이 실행하고 있다는 뜻이 됩니다.
    • V$Session을 조회하면, 혼자 작업 중인데도 많은 세션이 동작중임을 볼 수 있습니다.
    • 1명이 쓰는데도 많이 접속한 것을 볼 수 있지요.
    • Shared_Server_Sessions의 값은 항상 낮게 설정해야 합니다. 그래야만, 나중에 Shared Server가 꽉 차더라도 공간을 보장해줘서 후에, Dedicated Server를 예약할 수 있도록 합니다.
      
      
      

• 지정된 프로토콜에 대해 처음에 시작된 Dispatcher 수를 지정합니다.
• \는 줄바꿈표시 ㅡ.,ㅡ
• DISPATCHERS 매개변수
  데이터베이스 관리자는 DISPATCHERS 매개변수를 사용하여 각 디스패처에 대해 다양
  한 속성을 설정합니다.
  Oracle9i는 Oracle Net 서비스에서 사용되는 구문과 유사한 이름-값 구문을 지원하여 기
  존 속성과 추가 속성의 사양을 위치 독립적이며 대소문자를 구분하지 않는 방식으로 설
  정합니다.
  예:

Oracle Database Configuration Assistant를 사용하여 이 매개변수를 구성할 수 있습니다.

Dispatchers의 파라미터

 

• PROTOCOL
• ADDRESS
• DESCRIPTION
• DISPATCHERS
• SESSIONS
• LISTENER
• CONNECTIONS

---

• 동시에 실행될 수 잇는 최대 디스패쳐 프로세스 수 지정합니다.
• 처음 시작 시보다 더 많은 디스패쳐를 지정이 가능합니다.

---

 

• 인스턴스가 시작될 때 생성할 서버 프로세스의 수를 지정합니다.
• 이것은 Alter  명령어를 이용하여 늘리거나 줄일 수 있습니다.

---

 

• 시작 가능한 최대 Shared Server수를 지정합니다.
• 직접 조정하지 않아도, 나중에 오라클서버가 자동으로 늘렺부니다.
• Request Queue의 길이에 따라 공유서버의 구성이 달라집니다.

---

 

• 수신 및 송신 네트워크 세션에 사용할 수 있는 가상 Circuit의 총 수를 지정합니다.
• 전체 SGA 크기에 영향을 줍니다.

---

• 허용되는 Oracle Shared ServerUser 세션의 총 수를 지정합니다.
• 이 파라미터를 설정하면 전용서버에 대한 사용자 세션을 예약할 수 있습니다.
• LARGE_POOL_SIZE : UGA를 사용하기 위해 라지풀을 조정한다.

---

▶ 설정 확인

• 위의 명령을 실행하여 인스턴스가 시작될 때 디스패쳐가 리스너에 등록되었는지 확인합니다.
• 단일 연결을 설정하여 공유 서버를 통해 연결한 다음 V$Circuit 뷰를 질의하여 Shared Server 연결 당 하나의 항목만 표시되는지 확인합니다.

▶ 동적 뷰

• V$CIRCUITS
• V$SHARED_SERVER
• V$DISPATCHER
• V$SHARED_SERVER_MONITOR
• V$QUEUE
• V$SESSION
  

Shared Server (MTS) Diagnostics [ID 1005259.6]
		수정 날짜 29-SEP-2011     유형 BULLETIN     상태 PUBLISHED

In this Document
  Purpose
  Scope and Application
  Shared Server (MTS) Diagnostics
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 10.2.0.1 - Release: 8.1.5 to 10.2
Oracle Net Services - Version: 8.1.5.0.0 to 10.2.0.1.0   [Release: 8.1.5 to 10.2]
Information in this document applies to any platform.

Purpose

Introduction

This document contains information about the Shared Server configuration of the Oracle Database software and some of the SQL scripts necessary to gather diagnostic information with guidelines for interpreting results. Prior to Oracle 9.0, Shared Server was called Multi-Threaded Server; the name was changed to reflect the extensive enhancements made.

Scope and Application

Skill level rating for this Article: Intermediate

Shared Server (MTS) Diagnostics

Architecture of the Shared Server Database Configuration

The best position to be in will always be based on understanding. The components of the Shared Server database configuration consist of the Dispatchers and the Shared Servers. These components run as separate processes in the operating system (or threads in some operating systems). They interact with each other through the use of a Common Queue (CQ - also known as the Virtual Queue, of which there could be multiple CQs) and individual Dispatcher Queues. Both queues reside in the Shared Global Area (SGA) and are sized automatically by the database itself. Another component of Shared Server is not a process but an abstraction of the user session(more of an owned pointer), called a Virtual Circuit (VC). The communication between the Dispatchers and Shared Servers is primarily done by passing ownership of a Virtual Circuit from one to another.

Fig. 1: Diagram of Shared Server Architecture

 

The stages that Shared Server goes through are quite simple. After the client sends the connection request to the Listener, it will either redirect or hand off (called warm hand-off) the connection to the Dispatcher (the Dispatcher does not necessarily need to be on the same host as the Listener). Once the client has connected to a Dispatcher it stays connected to that Dispatcher. Before the client completes the database log in, the Dispatcher associates a Virtual Circuit (VC) for that database session. There exists exactly one row in the VC view (V$CIRCUIT) for each client connection. This view also shows the current status of the client's VC. Once the VC has been associated with the database session, the client will complete the database logon by passing the username and password to the Dispatcher. This request, as part of the VC for that new session, will be placed in the Common Queue where the first available Shared Server will complete the logon. Once each phase of the logon has completed, the Shared Server will pass the VC back to the Dispatcher, which then passes the response back to the Client (this actually takes several round trips to the client, in just the same manner as if it was a Dedicated connection).

Once the logon has completed, the client starts a normal conversation with the database. When the client makes a request to the database, it is the Dispatcher that picks up this request from the operating system's network protocol. The Dispatcher then determines which client session the request came from (remember that a Dispatcher can be configured for Connection Pooling and Multiplexing: see the Net Administration Guide for more information on those configurations), tags that sessions' VC that there is a new message (there is also a pointer to that session buffer in the VC) and places the VC in the Common Queue. The CQ is serviced by the Shared Servers on a first-in-first-out basis. The next available Shared Server pulls the VC from the CQ and processes the request. Part of the VC structure is the identity of the Dispatcher that created it (and which client is connected to it). When the Shared Server is finished processing the request, it writes the output to the session buffer, changes the VC's ownership back to the Dispatcher that created it, places the VC into that Dispatcher's queue, and posts the Dispatcher it has something in its queue. The Dispatcher then checks its queue and sends what is in the session buffer through the operating system network protocol back to the Client.

In the case where there is a request for a Database Link, it is the Shared Server process that will, from the link definition, create an outbound VC and place it into the least loaded Dispatcher's queue (not necessarily the same Dispatcher the Client is connected to). This Dispatcher then logs into the remote database and passes the query to it for processing. Once the remote database responds, the Dispatcher then places the VC back into that Shared Server's ownership.

The Dispatchers are not limited to just the Oracle Net protocol. They also are able to understand FTP, HTTP(S), WebDAV, IIOP, SMTP, and TCP protocols.

 

The main views containing Shared Server information include:

V$CIRCUIT
V$DISPATCHER
V$DISPATCHER_CONFIG
V$DISPATCHER_RATE
V$QUEUE
V$SESSION
V$SHARED_SERVER
V$SHARED_SERVER_MONITOR

Dispatchers: The Number Of Dispatchers

 

The number of Dispatchers present in a Shared Server database configuration may vary from zero up to the system INIT.ORA parameter of MAX_DISPATCHERS. The initial number of Dispatchers created at instance startup is the value defined by the DISPATCHERS parameter in the system INIT.ORA and can exceed the MAX_DISPATCHERS value (as of version 10). Both parameters can be altered at runtime by ALTER SYSTEM commands (version 9.0 onwards, consult the SQL Reference manual for the particular version being run).

It is the PMON database background process that starts or stops any background processes, such as Dispatchers and Shared Servers. Dispatchers are not dynamically started or stopped, but must be manually maintained. Apart from restarting the database in order for the database to take on a new value set in the INIT.ORA, the following command may also be issued while the database is running:


Where 'string' is a valid setting for the DISPATCHERS parameter. For example:


PMON creates or destroys Dispatchers and then informs the Listener with their current state. PMON also updates the Listener about every ten seconds (depending on system load and other factors) with the current number of sessions and database load. To have PMON update the Listener with a change outside its normal cycle (as long as the LOCAL_LISTENER and REMOTE_LISTENER parameters are properly set in the system INIT.ORA) use this command:

One can then query then Listener for the new services that have been registered:

From this output we can see that there are four dispatchers, two using TCP and two using TCPS. The TCP ports that are assigned to the Dispatchers were allocated by the operating system. To specify what port to use, each Dispatcher has to be configured individually specifying the port number in the ADDRESS parameter section (see the Oracle Net Administration Guide on how to assign ports to Dispatchers).

Dispatchers can also be configured for a particular service. By default, each Dispatcher will service all SERVICE_NAMES and the DB_NAME. Dispatchers can be set up to only service a specific Service.

 The command added one Dispatcher, D003, to service the SERVICE_NAME of V10R2_DISP (specified by the SERVICE clause). To get this Dispatcher to service V10R2_DISP the INDEX clause was used (INDEX can also be used to "separate" Dispatchers from other TCP Dispatchers). This new Dispatcher gets a new INDEX:

 If the desire is to add more Dispatchers for a particular protocol, either issue the ALTER SYSTEM command specifying the full DESCRIPTION of the Dispatcher, or the Dispatcher's INDEX. For example, below are three Dispatchers configured for TCP and one configured for TCPS and there is a need to add one more TCP Dispatcher:

Dispatchers: Shutting Down Dispatchers

If the need is to shut down or reduce the number of Dispatchers by using the ALTER SYSTEM statement, the database can decide, or a specific Dispatchers can be chosen. To identify the name of the specific Dispatcher process to shut down, use the V$DISPATCHER view.

Each Dispatcher is uniquely identified by a name of the form Dnnn (where n is a number in the 0-9 range). In Unix, the Dispatcher process will have a name like ora_dnnn_sid. For Windows, the Dispatchers run as threads and are only visible using certain utilities, but the Oracle views will be the same. The Dispatchers are grouped by CONF_INDX based on the DESCRIPTION (or ADDRESS and PROTOCOL).

To shut down Dispatcher D002, issue the following statement:

 

 

The Dispatcher stops accepting new connections and will wait until all of the sessions it handles are disconnected before shutting down.

For a more "immediate" shutdown of the Dispatcher (it is in a bad state or it won't shutdown with the above command) issue this command:

 

 

The IMMEDIATE keyword stops the Dispatcher from accepting new connections and immediately terminates all existing connections through that Dispatcher. After all sessions are cleaned up, the Dispatcher process shuts down.

When a Dispatcher is shut down, other Dispatchers will not inherit the name, so it is possible to see some Dispatchers missing. When starting up a new Dispatcher, it will obtain the next open Dispatcher name. In the case where TCPS D002 Dispatcher was shut down, and a new Dispatcher for TCP was started, the new Dispatcher will be called D002. 

Dispatchers: Monitoring Performance

In general, Dispatchers will not be very busy because their tasks are relatively quick to complete. In the example below, Dispatchers are less than 1% busy.

 The OWNED column of V$DISPATCHER view shows the number of clients currently connected to each Dispatcher. In the above example, a D000 has 26 clients connected. D000 is in the process of sending a message to a client as is shown by the SEND status. D004 has OWNED = 0 because it has just been started using the following command:

 

 

Dispatchers: Performance

One perspective for interpreting Dispatcher performance is measuring the wait times in the various queues by querying the view V$QUEUE.

 

In the above example, the WAIT column is the total amount of time all requests have waited in the particular queue. The TOTALQ column is the total number of requests in a queue since the startup of the database. The AVG WAIT denotes the average wait (in seconds) per queued request.

The row with the TYPE of COMMON represents the Common Queue. The CQ holds all client requests to be processed by the Shared Servers. Please note that V$QUEUE view is not related to the Oracle Streams Advance Queuing feature. 

Shared Servers: Setting the Quantity of Shared Servers

The quantity of Shared Server processes will vary between INIT.ORA parameters SERVERS and MAX_SERVERS. Initially, the MAX_SERVERS value should be set to some estimated maximum number. For the initial setting, it can be set to the maximum number of expected sessions on the database (this is just a suggestion as it could also be set to far less). The effect of setting this parameter to a large value only affects the size of the Common Queue. This parameter can be changed dynamically by issuing the command:

 

 

Setting the initial value for SERVERS is also estimated. It can be set to some number under the setting of MAX_SHARED_SERVERS. But once the system is running under production load, the parameter SERVERS can be changed to accommodate the load. The Oracle Database Performance Tuning Guide explains how to monitor V$QUEUE to determine if SERVERS should be increased:  

 If the system is suffering from high SYS load due to having to create and destroy many shared servers, then SERVERS might be set to one plus the number in SERVERS_HIGHWATER that is found in the V$SHARED_SERVER_MONITOR view (the name of the view is V$MTS in 8.1 and before).

Setting this parameter based on the SERVERS_HIGHWATER value will reduce the expense of process creation and match the known maximum of Shared Servers. These are just suggestions as to a starting point to configuring Shared Server. The Shared Server views should be monitored to make sure the settings are appropriate for this instance. Monitoring the instance initially to make sure the settings are correctly configured will assure a well-tuned system.

Shared Server Performance

Shared Servers are created by PMON. Upon instance startup, PMON will create them according to the value of the SHARED_SERVERS parameter. If more SHARED_SERVERS are needed, PMON will create them up to MAX_SHARED_SERVERS to meet the need. PMON will terminate idle Shared Servers until the number goes back to SHARED_SERVERS. When measuring the performance of the Shared Servers, it is normal to see the lower numbered Shared Servers to be busier then the higher numbered ones.

 

In the above example, all the Shared Servers are between 1% and 99% busy. Shared Server S008 is very busy processing a single client request and Shared Server S000 has been busy handling numerous smaller requests. In general, the S000 Shared Server will always be the busiest and could easily be 100% busy all the time. This is by design.

The reason that S003-S005 and S007 are not listed is because the SHARED_SERVER parameter was set to 3 so PMON removed those Shared Servers because they went idle long enough to be removed. The idle interval cannot be set, nor does it need to be as it is more efficient to not have to create a Shared Server. S006 and S008 are not idle so they will exist as long as there is work for them to do.

In the case where there is a gap in the %TIME BUSY, such as is illustrated above where higher numbered Shared Servers S006 and S008 are nearly 100% used. This could be due to some sessions having so much work to do that a Shared Server has been dedicated to that particular session. It is sessions like this that should be found and forced to connect with a Dedicated server processes. Such heavy sessions have enough continuous workload that the service time the Dispatcher adds may slow them down.

The STATUS column of the V$SHARED_SERVER view provides useful information about WAIT status. In particular, the WAIT(ENQ) status tells the DBA that the user is waiting for a lock resource, and in rare cases, acts as an alert for a deadlock situation.

An overview of server creation and termination and high-water mark is available from the V$SHARED_SERVER_MONITOR view.  

 

The MAXIMUM_CONNECTIONS is the value of the maximum number of Virtual Circuits in use at one time.

The MAXIMUM_SESSIONS is the highest number of Shared Server sessions in use at one time since the instance started.

The SERVERS_STARTED and SERVERS_TERMINATED columns maintain a running total of Shared Server process creation and termination by PMON (but do not include the number set in the SHARED_SERVERS parameter).

The SERVERS_HIGHWATER value holds the high-water mark for the Shared Server count since the instance startup.

These statistics are useful indicators to check if SERVERS is set too low or too high. If the SERVERS_STARTED or SERVERS_TERMINATED are zero, this is an indication that too many Shared Servers may have been configured. Similarly, if the values of SERVERS_STARTED and SERVERS_TERMINATED grow quickly, the number for SHARED_SERVERS is likely to be too low and should be set to SERVERS_HIGHWATER + 1 (the "+ 1" is for good measure and has no intrinsic meaning).

 

Virtual Circuits and Sessions

The SERVER column in the V$SESSION view shows the type of Server that is currently servicing each session.

In the above example, DEDICATED means that client is connected with a dedicated server process. Shared Server connections appear as NONE or SHARED depending on whether a task is currently being serviced by a Shared Server or not. In this case only the OS User "bill" is being serviced by a Shared Server.

The V$CIRCUIT view provides more detailed information about usage of circuits by each session.

 The DISPATCHER column identifies the Oracle process ID for the Dispatcher Associated with the session. The SERVER column provides the Oracle process ID for the Shared Server currently servicing the client session, and zero if the session is not being serviced. For the QUEUE column, NONE represents the circuit is idle, SERVER means it is currently being serviced by a Shared Server, DISPATCHER means it is being serviced by a Dispatcher, and COMMON means it is on the Common Queue waiting to be picked up by a Shared Server.

The WAITER column is the Oracle process ID of the process that is currently waiting for data to appear in the Circuit. It will contain "00" when no database operation is in progress, otherwise it will list the Oracle process id for the Dispatcher or a Shared Server. Dispatchers are very quick to complete their work, so quick that it is rare to catch a glimpse of a Dispatcher in the WAITER queue.

References

http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14220%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14231%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14211%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=network.102%2Fb14212%2Ftoc.htm&remark=portal+%28Books%29
Previous versions of the above manuals

첨부 파일 Shared_Server.jpg (62.28 KB)

관련 자료 제품 Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition Oracle Database Products > Oracle Database > Net Services > Oracle Net Services 키워드 DISPATCHER; DISPATCHERS; MTS; PERFORMANCE; SHARED SERVER

멀티 스레드 서버 개요

by Jeff Hunter, Sr. Database Administrator 제프 헌터, 미스터 데이터베이스 관리자에 의해

Contents 내용

1. Overview 개요
2. Benefits of MTS MTS의 장점
3. The Trade-offs 무역 오프
4. Implementing MTS 구현 MTS
5. Bottom Line: Should I use MTS? 결론 : 저는 MTS를 사용해야합니까?
6. Setting up your MTS environment 귀하의 MTS 환경 설정
   • How Many Dispatchers? 얼마나 많은 Dispatchers?
   • How Many Shared Server Processes? 얼마나 많은 공유 서버 프로세스?
   • How Much Memory? 메모리가 얼마나?
7. Changing Database Initialization Parameters 데이터베이스 초기화 매개 변수 변경
   • MTS_DISPATCHERS MTS_DISPATCHERS
   • MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS
   • MTS_SERVERS MTS_SERVERS
   • MTS_MAX_SERVERS MTS_MAX_SERVERS
   • LOCAL_LISTENER LOCAL_LISTENER
   • LARGE_POOL LARGE_POOL
8. Forcing a Dedicated Server Connection 전용 서버 연결을 강제
9. Viewing MTS Statistics MTS 통계보기
   • Operating-System Commands 운영 체제 명령
   • Listener Control 리스너 제어
   • Dynamic Performance Views 동적 성능보기

Overview 개요

Many Oracle DBAs today are faced with the every growing number of connections to their databases. 대부분의 오라클 DBAs 오늘날들은 데이터베이스에 연결마다 증가에 직면하고 있습니다. When using the traditional method of connecting to the database (dedicated server) each client process is given a dedicated server process that runs on the database server. 데이터베이스에 연결하는 전통적인 방법을 사용하는 경우 (전용 서버) 각 클라이언트 프로세스는 데이터베이스 서버에서 실행되는 전용 서버 프로세스를 제공합니다. This server process is sometimes referred to as a "shadow process". 이 서버 프로세스는 때때로 "그림자 프로세스"라고합니다. This server process takes memory away from the system and as the number of connections increase, so does the demand for memory. 이 서버 프로세스 때문에 메모리에 대한 수요가 않으며, 시스템에서와 연결 증가의 번호로 떨어진 메모리를 소요됩니다. Not only is memory in demand for with these server processes, but so are CPU requirements. 뿐만 아니라 이러한 서버 프로세스에 대한 수요의 메모리, 근데 CPU 요구 사항이 있습니다. If you have many users connecting and disconnecting from the database server, a good amount of CPU will be required in building and destroying these dedicated server processes. 당신이 연결하고 데이터베이스 서버에서 분리 많은 사용자가있다면, CPU의 좋은 금액이 전용 ​​서버 프로세스를 구축하고 파괴해야합니다.

Oracle provides a solution that answers the above two issues called Multi-Threaded Server. 오라클은 멀티 스레드 서버라는 위의 두 가지 문제 답을 솔루션을 제공합니다. This article provides some insight into setting up Multi-Threaded Server (MTS) as well as several scripts that can be used to monitor your MTS environment. 이 문서는 멀티 스레드 서버 (MTS)뿐 아니라 MTS 환경을 모니터링하는 데 사용할 수있는 몇 가지 스크립트 설정에 몇 가지 통찰력을 제공합니다.

Benefits of MTS MTS의 장점

Think about a system in which only 4 client processes need access to the database. 겨우 4 클라이언트 프로세스가 데이터베이스에 액세스해야하는 시스템에 대해 생각합니다. With dedicated server, each client process requires one dedicated server processes. 전용 서버로, 각 클라이언트 프로세스 하나의 전용 서버 프로세스를 필요로합니다. If each server process consumes 8 megabytes of memory, you will need 32 megabytes to support this scenario. 각 서버 프로세스가 메모리 8메가바이트를 소비한다면, 당신은이 시나리오를 지원하기 위해 32메가바이트 필요합니다. Now consider 100 dedicated connections. 지금 100 전용 연결 고려하십시오. In this scenario, you would require 800 megabytes of memory! 이 시나리오에서는 메모리 800 메가가 필요 것입니다! Using MTS, you can see in Figure 1 that these same 4 client connections can be supported by only 2 shared server processes. MTS를 사용하여, 당신은에서 볼 수있는 그림 1 이 동일한 4 클라이언트 연결에만이 공유 서버 프로세스에서 지원 수 있습니다.

Figure 1: Dedicated Server vs. Shared Server 그림 1 : 전용 서버 대 공유 서버

Another thing to consider is OLTP environment where users are spending most of their time reading and editing data on their screens and very little time actively executing SQL statements against the database. 고려해야 할 또 한가지는 사용자가 적극적으로 데이터베이스에 대해 SQL 문을 실행하는 자신의 화면 데이터와 거의 시간을 읽고 편집 대부분의 시간을 소비 아르 OLTP 환경입니다. In this scenario, many of those dedicated server processes are sitting idle and needlessly consuming memory. 이 시나리오에서는 이러한 전용 서버 프로세스의 대부분은 유휴 상태 및 불필요한 소비 메모리 앉아있다. Because MTS allows the sharing of the server process between many client processes, the DBA can now make more efficient use of the server processes. MTS는 많은 클라이언트 프로세스간에 서버 프로세스의 공유를 허용하기 때문에, DBA는 이제 서버 프로세스를보다 효율적으로 사용할 수 있습니다.

Lastly, MTS can improve with environments where clients are constantly connecting and disconnecting from the database. 마지막으로, MTS는 클라이언트가 지속적으로 연결하고 데이터베이스에서 연결을 해제 아르 환경 향상시킬 수 있습니다. Since shared server processes are not tied directly to a client process, they are not built and destroyed each time a client connects or disconnects. 공유 서버 프로세스가 클라이언트 프로세스에 직접 연결되어 아니므로, 그들은 건설과 클라이언트가 연결하거나 연결을 끊으 때마다 파괴되지 않습니다. Oracle will maintain an active "pool" of shared server processes. 오라클은 공유 서버 프로세스의 적극적인 "풀"을 유지합니다. New shared server processes are only created when demand exceeds supply. 수요가 공급을 초과하면 새로운 공유 서버 프로세스는 만들어집니다. On the same note, shared server processes are only destroyed when demand drops off and those extra shared server processes are no longer needed. 같은 메모에서 수요가 떨어져 방울 때 공유 서버 프로세스는 파괴되고 그 여분의 공유 서버 프로세스는 더 이상 필요하지 않습니다.

The following list outlines the advantages of using MTS: 다음 목록은 MTS를 사용의 이점을 설명합니다 :

• Reduced Demand for Memory : Since one server process can now handle many clients, you need fewer server processes, resulting in a reduced demand for overall memory. 메모리에 대한 수요를 감소 : 하나의 서버 프로세스가 현재 많은 클라이언트를 처리할 수 있기 때문에, 당신은 전체 메모리에 대한 수요 감소 결과, 적은 수의 서버 프로세스가 필요합니다.
• More Efficiency : Since there is less idle time with each shared server process, you gain more efficiency within each server process. 더 많은 효율성 : 각 공유 서버 프로세스와 적은 유휴 시간이 있기 때문에, 당신이 각 서버 프로세스 내에서 더 많은 효율성을 습득합니다.
• Fewer CPU Resources : Server processes are no longer being built and destroyed for each client connection and disconnect. 적은 CPU 리소스 : 서버 프로세스가 구축되지 않으며 파괴 각 클라이언트 연결과 분리되고 더 이상 없습니다. Fewer resources will now be required in the building and destroying of server processes. 적은 자원 이제 건물 및 서버 프로세스의 파괴 필요합니다.
• Communicating Through a Firewall : TCP/IP port numbers can be explicitly specified for MTS dispatchers. 방화벽을 통해 통신 : TCP / IP 포트 번호는 명시적으로 MTS의 dispatchers에 대해 지정할 수 있습니다. Knowing in advance the port numbers that will be used, can sometimes help when dealing with communicating through a firewall. 방화벽을 통해 통신을 다루는 때 사용되는 포트 번호, 가끔은 도움이 사전에 알고.

The Trade-offs 무역 오프

MTS is not for everyone! MTS는 모든 사람이 아니야! Before implementing MTS in your environment, keep the following in mind: 사용자 환경에서 MTS를 구현하기 전에 다음 사항에 유의 :

• Batch Jobs vs. Quick transactions : The use of MTS is predicated on the assumption that each client will use only a small fraction of its connect time to perform any work against the database. 일괄 채용 대 빠른 거래 : MTS의 사용은 각각의 클라이언트가 데이터베이스에 대해 어떤 작업을 수행하기 위해 연결하는 시간의 작은 파편만이를 사용하는 가정에 predicated입니다. The more active your clients are, the greater the number of shared server processes you will need to respond to their requests in a timely manner. 보다 적극적인 고객, 당신​​이 적시에 자신의 요청에 응답해야합니다 공유 서버 프로세스의 큰 수입니다. You may get to a point to where MTS ceases to make sense at all. MTS 전혀 이해하기 위해 중단 어디 지점에받을 수 있습니다. Batch jobs or clients that extract large amounts of data should not connect to the database through MTS. 대용량의 데이터를 추출 일괄 작업 또는 클라이언트가 MTS를 통해 데이터베이스에 연결해서는 안됩니다.
• Latency with MTS : When clients submit SQL statements to be executed, it now has to wait until a shared server process is freed up and can take on the task of executing the statement. MTS와 지연 : 클라이언트가 실행하는 SQL 문을 제출할 때, 지금 공유 서버 프로세스가 최대 해제하고 구문을 실행할 작업에 걸릴 수있을 때까지 기다려야한다. The amount of time depends on the number of shared server processes currently running and how busy they are. 시간 금액은 공유 서버의 현재 실행중인 프로세스와 방법에 바쁜 그들의 숫자에 따라 달라집니다.
• Client's Perspective : Even though the DBA may be reducing the demand for memory and/or CPU on the server, MTS will not result in better performance from the client's perspective. 고객의 관점 : DBA가 메모리 및 / 또는 서버에서 CPU에 대한 수요를 줄일 수있다하더라도, MTS는 고객의 관점에서 더 나은 성능의 결과되지 않습니다.

Implementing MTS 구현 MTS

After deciding MTS is right for your environment, it is now time to dig into the implementation details. MTS 바로 사용자 환경을위한 결정 후, 이제 구현 세부 사항에 팔 시간입니다. The DBA will need to consider the following two issues: User Session-Specific Data (UGA) and Routing Client Requests to Shared Server Processes . DBA는 다음과 같은 두 가지 문제를 고려하셔야합니다 : 사용자 세션 관련 데이터 (UGA)와 공유 서버 프로세스로 라우팅 클라이언트 요청합니다.

User Session-Specific Data (UGA) 사용자 세션 - 특정 데이터 (UGA)
Every connection to the Oracle database has a "session-specific" memory associated with it. Oracle 데이터베이스에 대한 모든 연결은 그것과 관련 "세션별로"메모리가 있습니다. This memory is referred to as the User Global Area (UGA) and is used to hold the values of PL/SQL variables, the values of bind variables and other items specific to a session. 이 메모리는 사용자 글로벌 영역 (UGA)이라고하고 PL / SQL 변수, 세션에 특정 바인딩 변수 및 기타 항목의 값을의 값을 보유하는 데 사용됩니다. The UGA also contains that part of the sort area specified by the SORT_AREA_RETAINED_SIZE initialization parameter. UGA는 또한 SORT_AREA_RETAINED_SIZE 초기화 매개 변수에 의해 지정된 정렬 영역의 일부를 포함하고 있습니다.

With a dedicated server connection, the UGA is stored within the dedicated server process's Program Global Area (PGA). 전용 서버 연결, UGA는 전용 서버 프로세스의 프로그램 글로벌 영역 (PGA) 내에 저장됩니다. When an MTS connection is made though, the UGA is stored in either the "LARGE POOL" or the "SHARED POOL". MTS 연결이 있지만 만든 경우, UGA는 중 "대형 수영장"또는 "공유 풀"에 저장됩니다. This difference is illustrated in Figure 2 . 이 차이는에있는 그림입니다 그림 2 .

In an MTS environment, the UGA needs to be moved into a common memory structure like the large pool or shared pool since it contains "session-specific" data. MTS 환경에서 UGA는 "세션 관련"데이터가 포함되어 있으므로 대형 풀 또는 공유 풀 같은 일반적인 메모리 구조로 이동해야합니다. Keep in mind that the use of MTS does not affect the overall "amount" of memory used for session specific data. MTS의 사용 세션이 특정 데이터에 사용되는 메모리의 전반적인 "금액을"에 영향을주지 않습니다 점에 유의하십시오. It is only moved from the memory space of the individual process into a common memory structure accessible by all processes. 그것은 모든 프로세스에 의해 액세스할 수있는 공통의 메모리 구조로 각 프로세스의 메모리 공간에서 이동됩니다.

Figure 2 shows the UGA located in the large pool. 그림 2는 대형 수영장에있는 UGA를 보여줍니다. If you do not have the large pool configured, then Oracle will place the UGA in the shared pool. 당신은 대형 수영장가 설정되지 않는 경우, 오라클은 공유 수영장에서 UGA를 배치합니다. Oracle does not recommend placing the UGA in the shared pool as this will cause fragmentation. 오라클은이 조각의 원인이되므로 공유 수영장에서 UGA를 배치하지 않는 것이 좋습니다.

Figure 2: MTS changes where session-specific information is stored 그림 2 : 세션과 관련된 정보가 저장되어있는 MTS 변경

Routing Client Requests to Shared Server Processes 공유 서버 프로세스로 클라이언트 요청을 라우팅
The second major issue of MTS is setting up the dispatcher. MTS의 두 번째 주요 문제는 배차를 설정입니다. When using a dedicate server connection, the client process simply passes the SQL statements to be executed to its dedicated server process. 헌정 서버 연결을 사용하면, 클라이언트 프로세스는 단순히 전용 서버 프로세스에 실행되도록 SQL 문을 전달합니다. What happens though when in an MTS environment the client process has no dedicated server process to send the SQL to? MTS 환경에서 클라이언트 프로세스가 SQL을 보낼 전용 서버 프로세스가없는 경우 어떻게 생각됩니까? The answer is that the request gets sent to a dispatcher process. 답변 요청 배차 프로세스로 전송된다는 점이다.

In an MTS environment, the dispatcher process assumes the role of communicating with the clients and routing your request. MTS 환경에서 배차 프로세스는 클라이언트와 통신하여 요청을 라우팅의 역할을 가정합니다. The listener no longer hands the client off to a dedicated server process, but rather gives each new client to the most lightly loaded dispatcher process. 리스너는 더 이상 손떼 전용 서버 프로세스는 클라이언트, 오히려 가장 가볍게로드 배차 프로세스에 각각의 새 클라이언트를 제공합니다. For the duration of the session, the dispatcher process will handle all communication with the client. 세션의 기간 동안, 배차 프로세스는 클라이언트의 모든 통신을 처리합니다.

The dispatcher processes will then take the requests (with are often SQL statements) from the client and place them into a request queue . 배차원 프로세스는 다음 클라이언트의 요청을 (종종 SQL 문을 아르와 함께) 가지고 요청 대기열에 넣어 것입니다. The request queue is located as a memory structure within the System Global Area (SGA) and is where all incoming requests are placed. 요청 대기열은 시스템 글로벌 영역 (SGA) 내의 메모리 구조로 위치하고 들어오는 모든 요청이 위치가 어디입니다. All shared servers you have setup within your instance will monitor the request queue. 귀하의 인스턴스 내에서 설정을 모든 공유 서버 요청 대기열을 모니터링합니다. When a request is entered into the request queue, the next available shared server process will pull it out of the queue and service it. 요청이 요청 대기열에 입력하면, 다음 사용 가능한 공유 서버 프로세스는 대기열의 그것을 꺼내 그것을 서비스합니다. All requests are handled in a first-in/first-out basis. 모든 요청은 first-in/first-out 기준으로 처리됩니다. This can be seen in Figure 3 . 이것은에서 볼 수있는 그림 3 .

Figure 3: Within an MTS setup, the dispatcher is responsible for all communication to and from the client 그림 3 : MTS 설정 내에서, 배차는 클라이언트와 모든 커뮤니케이 션에 대한 책임

When the shared server process completes the task, the results are placed into a response queue . 공유 서버 프로세스가 작업을 완료하면 그 결과는 응답 대기열에 배치됩니다. Like the request queue, the response queue is a memory structure located within the SGA. 요청 대기열과 마찬가지로, 응답 대기열은 SGA 내에있는 메모리 구조입니다. Response queues are directly tied to a specific dispatcher. 응답 대기열 직접 특정 배차에 묶여있다. While each dispatcher has its own response queue, each dispatcher on the other hand will have the same request queue. 각 배차 자체 응답 대기열을 가지고 있지만, 반면에 각각의 배차는 동일한 요청 대기열을해야합니다. When a dispatcher detects a response in its response queue, it will send that response back to the client that first initiated the request. 배차는 응답 대기열에 응답을 감지하면, 먼저 요청을 시작한 클라이언트에 다시 응답을 보내드립니다.

How many dispatchers should you use in your MTS environment? 당신의 MTS 환경에서 얼마나 많은 dispatchers를 사용해야합니까? Well, for one you will need at lease one dispatcher for each network protocol that you are supporting. 음, 한 당신은 임대에서이 지원하는 각 네트워크 프로토콜에 대해 하나 배차가 필요합니다. Like shown in Figure 3 , you created one dispatcher for TCP/IP and another for SPX. 표시와 마찬가지로 그림 3 , 당신은 SPX 한 TCP에 대한 배차 / IP와 다른 만들었습니다. Aside from the number of network protocols, you also need to decide on the number of connections you are planning to support. 외에 네트워크 프로토콜의 번호에서, 당신은 또한 지원을 계획하고 연결 수를 결정합니다. There is a limit as to how many connections that each dispatcher process can handle. 각 배차 프로세스가 처리할 수있는 얼마나 많은 연결로 제한이 있습니다. (This number is operating-system specific). (이 번호는 운영 체제에만 적용됩니다.)

Bottom Line: Should I use MTS? 결론 : 저는 MTS를 사용해야합니까?

Well, this depends on your environment. 음, 이것은 환경에 따라 다릅니다. If you are supporting a large number of client connections and where those connections are mostly inactive, then MTS would be ideal here. 당신은 클라이언트 연결의 많은 지원을하고 있으며 이러한 연결은 대부분 비활성 어디면 MTS는 여기에 이​​상적인 것입니다. MTS would not be a good setup if your environment does not involve much idle time with your client connections. 환경이 클라이언트 연결과 함께 많은 유휴 시간을 포함하지 않는 경우 MTS는 잘 설치되지 않을 것입니다. (ie batch jobs). (예 : 일괄 작업). Keep in mind that you setup an environment that allows for both MTS and dedicate server processes. 당신은 MTS 모두 수있는 환경을 설치 및 서버 프로세스를 바칩니다 점을 명심하십시오. Setup user connections who only sporadically accessing the database using MTS, while batch jobs and other data intensive connections can be made using dedicated server connections. 일괄 작업 및 기타 데이터 집약적인 연결이 전용 ​​서버 연결을 사용하여 만들 수있는 동안에만 간헐적으로, MTS를 사용하여 데이터베이스를 액세스하는 설치 사용자 연결. Lastly, remember that from the client's perspective, MTS does not enhance their performance, but rather reduces the CPU and memory overhead associated with supporting many client (mostly idle) connections. 마지막으로, 클라이언트의 관점에서, MTS는 자신의 성능을 향상하지 않는 기억, 오히려 많은 클라이언트 (대부분 유휴 상태) 연결 지원과 관련된 CPU 및 메모리 오버헤드를 줄일 수 있습니다.

Setting up your MTS environment 귀하의 MTS 환경 설정

How Many Dispatchers? 얼마나 많은 Dispatchers?
As discussed above, you will need to provide at lease one dispatcher process for each protocol you plan on supporting. 위에서 설명한대로, 당신은 지원 계획이 각 프로토콜에 대해 임대 하나 배차 과정을 제공해야합니다. Another factor that will affect your decision on the number of dispatcher processes is the operating system's limit on the number of connections that can be made to a single process. 배차원 프로세스의 수를 결정에 영향을줍니다 또 다른 요인은 단일 프로세스로 만들 수있는 연결의 수를 운영 체제의 한계입니다. If for example, your operating system allows a maximum of 972 connections to one process, and you want to support 3500 TCP/IP connections using MTS, then you will need a minimum of four (4) dispatcher processes for the TCP/IP network protocol. 예를 들어 경우, 운영 체제가 하나의 처리 972 연결의 최대 허용하고 3500 TCP / MTS를 사용하여 IP 연결을 지원하려면, 다음의 TCP / IP 네트워크 프로토콜에 대한 4 배차 프로세스의 최소 필요합니다 .

Determining OS Connection Limits OS 연결 제한을 결정

Determining the connection limit for your particular operating system is fairly easy. 특정 운영 체제에 대한 연결 제한을 결정하는 것은 매우 쉽습니다. You will need to use the "SERVICES" command within the Listener Control utility. 당신은 리스너 제어 유틸리티 내에서 "서비스"명령을 사용해야합니다. Simply perform the following tasks: 간단히 다음과 같은 작업을 수행합니다 Use the MTS_DISPATCHERS initialization parameter to configure a test database for one dispatcher. 한 배차를위한 테스트 데이터베이스를 구성 MTS_DISPATCHERS 초기화 매개 변수를 사용합니다. Stop and restart your instance to read in the new value of MTS_DISPATHCERS. 중지하고 MTS_DISPATHCERS의 새로운 가치를 읽을 수 인스턴스를 다시 시작합니다. Run the Listener Control utility and issue the SERVICES command. 리스너 제어 유틸리티를 실행하고 서비스 명령을 발행하고 있습니다. The output will include a list of dispatcher processes. 출력은 배차 프로세스의 목록을 포함합니다. Now find the dispatcher process in the list of services and look at the value for max . 이제 서비스 목록에서 배차 과정을 찾아 최대의 값을보세요. This value indicates the maximum number of connections that your operating system allows for one process. 이 값은 운영 체제 하나의 프로세스에 대해 허용되는 연결의 최대 개수를 나타냅니다. Here is a small sample. 여기에 작은 샘플입니다. Note that the value for max is 972. 최대 값은 972입니다. LSNRCTL> SERVICES LSNRCTL> 서비스 Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=SOPDEV2.world)) 에 연결 (= (PROTOCOL = IPC) (KEY = SOPDEV2.world을 주소)) Services Summary... 서비스 요약 ... Service "SOPDEV2" has 2 instance(s). 서비스 "SOPDEV2는"2 인스턴스 (들)을하고 있습니다. Instance "SOPDEV2", status UNKNOWN, has 1 handler(s) for this service... 예를 들어 "SOPDEV2"상태 알 수없는이 서비스에 대해 1 처리기 (들)을했습니다 ... Handler(s): 처리기 (들) : "DEDICATED" established:0 refused:0 "전용"설립 : 0 거절 : 0 LOCAL SERVER 로컬 서버 Instance "SOPDEV2", status READY, has 2 handler(s) for this service... 예를 들어 "SOPDEV2"상태가 준비,이 서비스 2 처리기 (들)을했습니다 ... Handler(s): 처리기 (들) : "DEDICATED" established:0 refused:0 state:ready "헌신"은 설립 : 0 거부 : 0 상태 : 준비 LOCAL SERVER 로컬 서버 "D000" established:0 refused:0 current:0 max:972 state:ready "D000"은 설립 : 0 거절 : 0 현재 : 0 최대 : 972 상태 : 준비 DISPATCHER 배차원 (ADDRESS=(PROTOCOL=tcp)(HOST=appdev)(PORT=47594)) (주소 = (PROTOCOL = TCP) (HOST = appdev) (포트 = 47594)) NOTE : Do not attempt to perform the above test on a production database when users are trying to connect. 참고 : 사용자가 연결하려고하는 경우 프로덕션 데이터베이스에서 위의 테스트를 수행하지 마십시오. In fact, use a "testing" database to ensure that you will not create connection problems for people in your production environment. 사실, 당신이 프로덕션 환경에있는 사람에 대한 연결 문제를 생성하지 않도록하기 위해 "테스트"데이터베이스를 사용합니다.

Table 1: Determining OS Connection Limits 표 1 : OS 연결 제한을 결정

How Many Shared Server Processes? 얼마나 많은 공유 서버 프로세스?
Setting up the number of shared server processes requires the use of two initialization parameters: MTS_SERVERS and MTS_MAX_SERVERS. MTS_SERVERS 및 MTS_MAX_SERVERS : 공유 서버 프로세스의 수를 설정은 두 초기화 매개 변수를 사용해야합니다. They control both the minimum and maximum number of shared server processes that you want to create for your instance. 그들은 당신이 예를 들면 만들려는 공유 서버 프로세스의 모두 최소 및 최대 개수를 제어합니다.

• MTS_MAX_SERVERS: Sets an upper limit on the number of shared server processes that can be created for the instance. MTS_MAX_SERVERS :이 인스턴스에 대해 만들 수있는 공유 서버 프로세스의 숫자에 상한선을 설정합니다. Ensure to choose a value for this parameter based on the total amount of resources you are willing to dedicate to all server processes. 당신은 모든 서버 프로세스에 헌정하고자하는 자원의 총액을 기준으로이 매개 변수에 대한 값을 선택할 수 있는지 확인하십시오.
• MTS_SERVERS: Sets the number of shared servers to initially create. MTS_SERVERS이 : 처음 만들 공유 서버의 수를 설정합니다. The default value is 1. 기본값은 1입니다. You should set this value to one higher than what reflects the typical load on your system. 여러분의 시스템에 전형적인 부하를 반영하는보다 높은 하나에이 값을 설정해야합니다. Keep in mind that the goal here is to minimize the rate at which shared server processes are being built and destroyed. 여기서 목표는 공유 서버 프로세스 구축하고 파괴되는 속도를 최소화하는 것입니다 점에 유의하십시오.

How Much Memory? 메모리가 얼마나?
Before implementing MTS in your environment, you will need to decide how much shared pool or large pool memory is required for session-specific memory. 사용자 환경에서 MTS를 구현하기 전에 공유 수영장이나 대형 풀 메모리가 세션 특정 메모리가 필요합니다 어느 정도 결정이 필요합니다. An easy way to do this, is to gather the current amount of memory used by a representative session, and then extrapolate from that to cover the number of sessions you expect to have simultaneously. 이 작업을 수행하는 쉬운 방법은 대표적인 세션에 의해 사용된 메모리의 현재 금액을 모아 다음 동시에 가지고 있다고 기대 세션의 수를 커버 것과 추정하는 것입니다. Suppose I want to gather memory information from a user logged in as "JHUNTER". 난 "JHUNTER"로 로그 인한 사용자의 메모리 정보를 수집하려는 가정합시다. First you will need to get the "SID" for the "JHUNTER" user. 먼저 "JHUNTER"사용자에 대한 "SID"를 얻을해야합니다. After obtaining the proper SID, select the current "UGA memory" and "UGA memory max" from v$sesstat. 적절한 SID를 취득 후, 현재 "UGA 메모리"를 선택하고 V $ sesstat에서 "UGA 메모리 최대".

  SQL> SELECT sid FROM v$session WHERE username = 'JHUNTER'; SQL> SELECT 시드 V $ 세션에서 WHERE 이름 = 'JHUNTER';

         SID SID
  ---------- ----------
          15 15


  SQL> SELECT sn.name, ss.value SQL> SELECT sn.name, ss.value
    2 FROM v$sesstat ss, v$statname sn V $ sesstat SS, V $ statname SN에서 2
    3 WHERE ss.statistic# = sn.statistic# 3 WHERE ss.statistic # = sn.statistic #
    4 AND sn.name IN ('session uga memory', 'session uga memory max') 4 ( '세션 uga 메모리', '세션 uga 메모리 최대')에 sn.name
    5 AND ss.sid=15; 5 ss.sid = 15;

  NAME VALUE 이름 값
  ------------------------ ---------- ------------------------ ----------
  session uga memory 54364 세션 uga 메모리 54,364
  session uga memory max 57076 세션 uga 메모리 최대 57,076 

The session uga memory value represents the amount of memory that a user is currently using for session-specific information. 세션 uga 메모리 값은 사용자가 현재 세션 관련 정보를 사용하는 메모리의 양을 나타냅니다. The other value, session uga memory max represents the maximum amount of session-specific memory that has been used at any one time during the user's current session. 다른 값은 세션 uga 메모리 최대는 사용자의 현재 세션 동안 한 번에 사용되었습니다 세션 특정 메모리의 최대 크기를 나타냅니다. Lets say that the "JHUNTER" user (above) was representative of many of the other users in the database that are going to connect via MTS, and you expected 500 such connections concurrently, simply multiply both values ( session uga memory and session uga memory max ) by 500 to come up with an estimated range of 27,182,000 to 28,538,000 bytes. 하자가 "JHUNTER"사용자 (위) MTS를 통해 연결하려고하는 데이터베이스에있는 다른 사용자의 많은 대표라고 이야기하고 동시에 500과 같은 연결을 예상, 단순히 두 값 (세션 uga 메모리와 세션 uga 메모리 곱하면 최대) 500 27182000로 28,538,000 바이트의 예상 범위로 올라와 있습니다. This will be the amount of additional memory that you will need to allocate in the SGA for use by these 500 MTS sessions. 이것은 여러분이 이러한 500 MTS 세션에 의해 사용을 위해 SGA에 할당하는 번거로움이 따른다는 것을 추가 메모리의 양을 것입니다. Remember that MTS uses the shared pool for session memory, but Oracle recommends the use of the large pool. MTS는 세션 메모리 공유 풀을 사용하지만, 오라클은 대형 수영장의 사용을 권장 것을 기억하십시오. By using the large pool, you avoid fragmenting the shared pool. 큰 수영장을 사용하여 공유 수영장 fragmenting하지 마십시오. Given the above example, I would add the following to my init.ora file: 위의 예제 감안할 때, 내 init.ora 파일에 다음을 추가합니다 :

  large_pool = 32M large_pool = 32M 

The above allocates a large pool of 32 MB in size. 위의 크기는 32 MB 중 대형 수영장을 할당합니다. This is all you really have to do in order to have Oracle use it for MTS session memory. 이것은 당신이 정말로 오라클 MTS 세션 메모리를 사용할 권한을 부여하기 위해해야​​ 할 전부입니다.

Changing Database Initialization Parameters 데이터베이스 초기화 매개 변수 변경

When thinking about setting up your MTS environment, you might be tempted to think that this will require changes to your Net8 configuration files like the listener.ora. 귀하의 MTS 환경을 설정하는 방법에 대해 생각하면, 당신이이 listener.ora처럼 Net8 구성 파일의 변경 사항을 요구할 것입니다 생각하는 유혹 수도 있습니다. As you will see, this is not the case. 당신이 볼 수로서,이 사건 없습니다. All parameters for setting up your MTS environment are made to the instance and not any your Net8 config files. 귀하의 MTS 환경 설정에 대한 모든 매개 변수는 모든 사용자 Net8 설정 파일이 아닌 인스턴스로 만들어 있습니다. Remember that the dispatcher and shared processes are actually part of the instance, so it makes sense that you would configure them in the same place. 배차 및 공유 프로세스가 실제로 인스턴스의 일부하므로 그것은 당신이 같은 장소에서 그들을 구성하는 것이 의미가 있습니다.

This section of the article discusses the changes that will need to be made to the following parameters: 문서의이 섹션에는 다음과 같은 매개 변수를 만들해야합니다 변경 사항을 설명합니다 :

• MTS_DISPATCHERS MTS_DISPATCHERS
• MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS
• MTS_SERVERS MTS_SERVERS
• MTS_MAX_SERVERS MTS_MAX_SERVERS
• LOCAL_LISTENER LOCAL_LISTENER
• LARGE_POOL LARGE_POOL

Setting up an MTS environment can be as simple as adding one or more MTS_DISPATCHERS parameters to your instance parameter file and then bouncing the database. MTS 환경을 설정하면 인스턴스 매개 변수 파일에 하나 이상의 MTS_DISPATCHERS 매개 변수를 추가하고 다음 데이터베이스를 수신 거부로 간단 수 있습니다. It's likely however, that you're going to want to tune some of the other parameters above. 그것은 당신이 위의 다른 매개 변수 중 일부를 조정하려는 거라고, 그러나 가능성이 높습니다.

MTS_DISPATCHERS MTS_DISPATCHERS

This is the key initialization parameter that needs to be set in order to implement MTS. 이것은 MTS를 구현하기 위해 설정하는 데 필요한 핵심 초기화 매개 변수입니다. The syntax here is very similar to what you would use in Net8 configuration files like the listener.ora file. 여기서 문법은 listener.ora 파일처럼 Net8 구성 파일에 사용할 것과 매우 유사합니다.

Here is an example of enabling MTS by only specifying the protocol to support. 여기에만 지원하는 프로토콜을 지정하여 MTS를 사용의 예입니다. This will accept default values for all other attributes: 이것은 다른 모든 속성에 대한 기본값을 수락합니다

  MTS_DISPATCHERS="(PROTOCOL=TCP)" MTS_DISPATCHERS = "(PROTOCOL = TCP)" 

If you want to support more than one protocol (TCP/IP and SPX for example), you would enter two MTS_DISPATCHERS parameter settings: 하나 이상의 프로토콜 (TCP / IP와 예를 들어, SPX)을 지원하려면 두 MTS_DISPATCHERS 매개 변수 설정을 입력합니다 :

  MTS_DISPATCHERS="(PROTOCOL=TCP)" MTS_DISPATCHERS = "(PROTOCOL = TCP)"
  MTS_DISPATCHERS="(PROTOCOL=SPX)" MTS_DISPATCHERS = "(프로토콜 = SPX)" 

NOTE : When declaring multiple MTS_DISPATCHERS parameters, they must be grouped together in the init.ora file. 참고 : 여러 MTS_DISPATCHERS 매개 변수를 선언하면, 그들은 init.ora 파일에 함께 그룹화해야합니다. Blank links are allowed, but do not place any other parameter settings between two MTS_DISPATCHERS settings. 빈 링크는 사용할 수 있습니다,하지만 아직 두 MTS_DISPATCHERS 설정 사이에 다른 매개 변수 설정을 올려 놓지 마십시오. Doing this will cause the instance to error when you try to start it. 이렇게하면 인스턴스가 당신이 그것을 시작하려고 할 때 오류가 발생할 것입니다.

Two other commonly used attributes in the MTS_DISPATCHERS are setting the "number of dispatchers" and maybe the "number of connections" each dispatcher is allowed to handle. MTS_DISPATCHERS에 두 기타 일반적으로 사용되는 속성은 "dispatchers의 개수"를 설정하고 아마 "연결 번호는"각 배차가 처리할 수 있습니다. The following example allocates four TCP/IP dispatchers and each of those dispatchers can handle up to 250 connections. 다음 예제에서는 네 개의 TCP / IP dispatchers 그 dispatchers 각각 최대 250 연결 처리할 수를 할당합니다.

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4)(CONNECTIONS=250)" MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 4) (연결 = 250)" 

Another attribute that deserves attention for MTS_DISPATCHERS is the LISTENER attribute. MTS_DISPATCHERS에 대한 관심을받을 자격이 다른 속성은 리스너의 속성입니다. The LISTENER attribute allows you to specify the listener with which the dispatcher should register. 리스너 속성은 배차 등록해야되는 수신기를 지정할 수 있습니다. By default, the dispatcher will register with the listener that is monitoring port 1521 on the local database server. 기본적으로, 배차는 로컬 데이터베이스 서버에서 포트 1521를 감시하는 리스너로 등록합니다. Using the LISTENER attribute though, you can override this and have your dispatcher register with a listener assigned to either a different port or with a listener running on another database server. 수신기 속성을 사용하면 불구하고,이를 무시하고 배차가 다른 포트를 하나에 할당된 리스너 또는 다른 데이터베이스 서버에서 실행되는 리스너 등록을 할 수 있습니다. The following is an example of using the LISTENER attribute: 다음은 수신기 속성을 사용하는 예입니다 :

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4)(CONNECTIONS=250) \ MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 4) (연결 = 250) \
                   (LISTENER=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(PORT=1526)(HOST=cartman))))" (리스너 = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (PORT = 1526) (HOST = cartman ))))" 

Here the LISTENER attribute defines an ADDRESS_LIST containing one or more listener addresses. 여기 리스너 특성은 하나 이상의 리스너 주소를 포함 ADDRESS_LIST을 정의합니다. The dispatchers will then register with each of those listeners. dispatchers 그러면 그 청취자의 각 등록합니다.

NOTE : There is also a LOCAL_LISTENER initialization parameter that provides the same functionality as the MTS_DISPATCHERS parameter's LISTENER attribute. 참고 : MTS_DISPATCHERS 매개 변수의 수신기 속성과 동일한 기능을 제공 LOCAL_LISTENER 초기화 매개 변수도 있습니다. The LISTENER attribute will override the LOCAL_LISTENER parameter and is the recommended by Oracle Corp. 리스너의 속성은 LOCAL_LISTENER 매개 변수를 무시하고 오라클 주식 회사에 의해 추천

One final note to make in reference to setting the MTS_DISPATCHERS is where you have the option of specifying the network address that it will monitor. MTS_DISPATCHERS 설정에 대한 참고 자료를 만들기 위해 마지막으로 참고 당신이 모니터링 네트워크 주소를 지정하는 옵션을 가지고있는 것입니다. (Similar to how you would set the listener process to listen on port 1521). (여러분이 포트 1521에서 수신 대기하는 리스너 프로세스를 설정해야하는 방법과 유사). One of the major reasons for forcing the port number for dispatchers is get around firewall issues. dispatchers에 대한 포트 번호를 강제의 주요 이유 중 하나는 방화벽 문제를 해결할 수 있습니다.

By default, whenever you specify the protocol to support, the dispatcher will decide on the address automatically. 기본적으로, 당신이 지원하는 프로토콜을 지정할 때마다 배차가 자동으로 주소를 결정합니다. You have the option though of specifying which address the dispatcher uses by replacing the PROTOCOL attribute with either the ADDRESS or DESCRIPTION attribute. 당신은 배차가 주소 또는 설명 속성 중 하나와 프로토콜 속성을 대체하여 사용하는 주소 지정지만 옵션이 있습니다. Below is an example that uses the ADDRESS attribute. 아래의 주소 속성을 사용하는 예제입니다. Also notice that in order to specify a port, that ALL dispatchers must be configured separately to ensure that no two dispatchers are sharing the same address: 또한 모든 dispatchers가 더이 dispatchers가 동일한 주소를 공유하지 않습니다 않도록 별도로 구성해야합니다 즉, 포트를 지정하기 위해서는 그 통지 :

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1562)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1562)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1563)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1563)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1564)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1564)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1565)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1565)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) " 

MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS

The MTS_MAX_DISPATCHERS parameter defines an upper limit on the number of dispatchers that can be running at any one time. MTS_MAX_DISPATCHERS 매개 변수는 한 번에 실행할 수 dispatchers의 숫자에 상한선을 정의합니다. The default value for this parameter is 5. 이 매개 변수의 기본 값은 5가된다. Keep in mind that this value is subject to modification based on your values defined in MTS_DISPATCHERS. 이 값이 MTS_DISPATCHERS에 정의된 해당 값을 기준으로 변경 적용됩니다 점에 유의하십시오. Examine the following example. 다음 예제를 검사합니다.

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=12)(CONNECTIONS=250)" MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 12) (연결 = 250)"
  MTS_DISPATCHERS="(PROTOCOL=SPX)(DISPATCHERS=10)(CONNECTIONS=250)" MTS_DISPATCHERS = "(프로토콜 = SPX) (DISPATCHERS = 10) (연결 = 250)"
  MTS_MAX_DISPATCHERS=16 MTS_MAX_DISPATCHERS = 16 

Given the example above, the actuall value for MTS_MAX_DISPATCHERS would be adjusted upward to 22. 위의 예제 감안할 때, MTS_MAX_DISPATCHERS에 대한 actuall 값이 22 위를 조정 것입니다. (12 for TCP and 10 for SPX) (TCP 12 및 SPX에 대한 10)

MTS_SERVERS MTS_SERVERS

The MTS_SERVERS parameter controls the number of shared server processes that will be available to service MTS connections. MTS_SERVERS 매개 변수는 서비스 MTS 연결을 사용할 수 있습니다 공유 서버 프로세스의 수를 제어합니다. With this parameter, you are defining the number of shared server processes that will be created when the instance starts. 이 매개 변수를 사용하면 인스턴스가 시작될 때 생성됩니다 공유 서버 프로세스의 개수를 정의하고 있습니다. (This is also the minimum number of servers for the instance. Oracle will not reduce the number of server processes below this number). (이것은 또한 인스턴스에 대한 서버의 최소 횟수입니다. 오라클은이 번호를 아래의 서버 프로세스의 수를 감소되지 않습니다.)

MTS_MAX_SERVERS MTS_MAX_SERVERS

The MTS_MAX_SERVERS parameter puts in place an upper limit on the number of shared server processes that can be running at any given time. MTS_MAX_SERVERS 매개 변수는 장소에서 언제든지 실행할 수있는 공유 서버 프로세스의 숫자에 상한선을 저장합니다. While an instance is running, the number of shared server processes increases and decreases. 인스턴스가 실행되는 동안, 공유 서버의 수가 증가 및 감소를 처리합니다. However, the number of shared server processes will never exceed the limit placed by use of the MTS_MAX_SERVERS parameter. 그러나, 공유 서버 프로세스의 숫자는 MTS_MAX_SERVERS 매개 변수를 사용하여 배치 한도를 초과하지 않습니다.

LOCAL_LISTENER LOCAL_LISTENER

As mentioned above, the LOCAL_LISTENER parameter serves the same purpose of the LISTENER attribute of the MTS_DISPATCHERS parameter. 위에서 언급한 바와 같이, LOCAL_LISTENER 매개 변수는 MTS_DISPATCHERS 매개 변수의 수신기 속성의 동일한 목적을 제공합니다. It identifies the listener with which MTS dispatchers will register with. 그것은 MTS의 dispatchers 함께 등록됩니다있는 수신기를 나타냅니다. Below are two example of setting this parameter: 아래의이 매개 변수를 설정하는 두 가지 예를 들면 다음과 같습니다 :

  LOCAL_LISTENER="(ADDRESS_LIST= \ LOCAL_LISTENER = "(ADDRESS_LIST = \
                           (ADDRESS= \ (주소 = \
                             (PROTOCOL=TCP) \ (PROTOCOL = TCP) \
                             (HOST=cartman) \ (HOST = cartman) \
                             (PORT=1526) \ (포트 = 1526) \
                           ) \ ) \
                         )" ) " 

  LOCAL_LISTENER="(ADDRESS_LIST= \ LOCAL_LISTENER = "(ADDRESS_LIST = \
                           (ADDRESS= \ (주소 = \
                             (PROTOCOL=TCP) (PROTOCOL = TCP)
                             (HOST=localhost) (= localhost를 호스트)
                             (PORT=1521) (PORT = 1521)
                           ) )
                           (ADDRESS= (= 해결
                             (PROTOCOL=IPC) (PROTOCOL = IPC)
                             (KEY=O901DB) (KEY = O901DB)
                           ) )
                         )" ) " 

The first example specifies one listener address. 첫번째 예제 하나의 수신기의 주소를 지정합니다. Since the port for this listener is 1526, rather than the default of 1521, this is considered a non-default listener. 이 리스너에 대한 포트가 1526이기 때문에, 오히려 1521의 기본보다, 이것은 기본이 아닌이 리스너로 간주됩니다. The second example shows two addresses and also represents the default value for the LOCAL_LISTENER parameter. 두 번째 예제는 두 개의 주소를 보여줍니다 또한 LOCAL_LISTENER 매개 변수에 대해 기본값을 나타냅니다.

Consider the following when trying to decide on whether to use the LOCAL_LISTENER init.ora parameter or the LISTENER attribute of MTS_DISPATCHERS. LOCAL_LISTENER init.ora 매개 변수 또는 MTS_DISPATCHERS의 수신기 속성을 사용할지 여부를 결정하려고 할 때 다음을 고려하십시오. Using the LISTENER attribute gives you finer control; you can have different dispatchers register with different listeners. 수신기 속성을 사용하면 당신에게 미세한 제어 기능을 제공하며, 다른 dispatchers 다른 청취자가 등록을 할 수 있습니다. LOCAL_LISTENER on the other hand, provides global control. 반면에 LOCAL_LISTENER가 글로벌 제어를 제공합니다. Oracle still recommends the use of the LISTENER attributed defined in the MTS_DISPATCHERS parameter. 오라클은 여전히​​ MTS_DISPATCHERS 매개 변수에 정의된 리스너 귀속의 사용을 권장합니다.

LARGE_POOL LARGE_POOL

We have discussed the use of the LARGE_POOL several times in this article. 우리는이 문서에 나와있는 LARGE_POOL 여러 번의 사용을 논의했습니다. Although it is not and MTS specific parameter, it is something that needs strong consideration when implementing MTS. 그것이 MTS 특정 매개 변수가 아니므로이지만, MTS를 구현할 때 강한 배려를 필요로 무언가이다. If your instance does not have a large pool defined, the session specific memory for all MTS connections will be taken from the shared pool. 인스턴스는 정의된 대형 수영장이 없다면, 모든 MTS 연결 세션 특정 메모리는 공유 수영장에서 가져온 것입니다. Have MTS take from the shared pool causes fragmentation and is not the recommended configuration from Oracle. 공유 수영장 조각을 원인과 오라클의 권장 구성하지 않습니다에서 MTS를 취할 있습니다.

Forcing a Dedicated Server Connection 전용 서버 연결을 강제

Remember that when configuring MTS requires no changes being made to your Net8 config files. MTS를 구성할 때해도 Net8 설정 파일을 만들어도되고 변경이 필요 없다는 것을 기억하십시오. MTS configuration happens at the instance level, and when configured, new connections start using it. MTS 구성 인스턴스 수준에서 발생하고 구성할 때, 새로운 연결을 사용하여 시작합니다. One thing you can control though through the use of your Net8 config files, is forcing a dedicated connection. 귀하의 Net8 설정 파일의 사용을 통해 제어할 수 있지만 한 가지는 전용 연결을 강제합니다. (Overriding the MTS configuration at the instance). (인스턴스에 MTS 구성을 우선). There are basically two ways to force a dedicated server connection: tnsnames.ora and sqlnet.ora. tnsnames.ora와 sqlnet.ora : 전용 서버 연결을 강제하는 방법은 두 가지가 기본적으로 있습니다.

tnsnames.ora tnsnames.ora
Simply add the attribute (SERVER=DEDICATED) to the list of CONNECT_DATA attributes. 간단히 CONNECT_DATA 속성 목록에 속성 (서버 = 전용)을 추가합니다.

  O901DB_DEDICATED.world = O901DB_DEDICATED.world =
  (DESCRIPTION = (DESCRIPTION =
     (ADDRESS_LIST = (ADDRESS_LIST =
         (ADDRESS = (= 해결
            (PROTOCOL = TCP) (PROTOCOL = TCP)
            (Host = cartman) (호스트 = cartman)
            (Port = 1521) (포트 = 1521)
         ) )
     ) )
     (CONNECT_DATA = (CONNECT_DATA =
         (SID = O901DB) (SID = O901DB)
         (SERVER = DEDICATED) (서버 = 전용)
     ) )
  ) ) 

sqlnet.ora sqlnet.ora
Use the USE_DEDICATED_SERVER=ON in the sqlnet.ora file to force EVERY session that you initiate from your client to use dedicated server. 당신은 전용 서버를 사용하도록 클라이언트에서 시작하는 모든 세션을 강제로 sqlnet.ora 파일에 = ON USE_DEDICATED_SERVER을 사용합니다. As you can see, this is a much less flexible approach as it does not allow for specific connections to use dedicate server. 당신이 볼 수 있듯이, 이것은 서버를 바치고 사용하는 특정 연결을 허용하지 않는 등 훨씬 덜 유연한 접근 방식이다.

Viewing MTS Statistics MTS 통계보기

Operating-System Commands 운영 체제 명령

Within UNIX and Linux, each dispatcher and shared server process is a separate operating-system process. UNIX 및 Linux, 각 배차 및 공유 서버 프로세스 내에서 별도의 운영 체제 프로세스입니다. The exact naming format varies from platform to platform, but the dispatcher process will always have the format d xxx in their name, and the shared server process will always have s xxx in their name. 정확한 명명 형식은 플랫폼에서 플랫폼으로 다양하지만, 배차 프로세스는 항상 그들의 이름에서 형식 D의 XXX가되며, 공유 서버 프로세스는 항상 자신의 이름 님의 XXX를해야합니다. In almost all cases, the xxx will be a number starting at 000. 거의 모든 경우에, XXX는 000부터 시작 번호가됩니다. This number gets incremented sequentially for each new dispatcher and/or shared server process started. 이 번호는 각각의 새로운 배차 및 / 또는 공유 서버 프로세스 시작에 대해 순차적으로 증가된옵니다.

On most UNIX system, you can make use of the ps command to generate a list of these processes. 대부분의 UNIX 시스템에서는 PS 명령의 사용이 프로세스의 목록을 생성하실 수 있습니다. You would then pipe this output into the grep command to filter out the ones that you are interested in. The following is an example: 당신은 grep 명령으로 파이프이 출력을 다음 예입니다 인치 자네가 관심이되는 것들을 걸러 다음과 같습니다

  O901DB on cartman: ps -ef | grep ora_[ds][0123456789]*_O901DB cartman에 O901DB : PS - EF | grep ora_ [DS] [0123456789] * _O901DB
  oracle 8742 1 0 Feb 06 ? 오라클 8742 1 0 2월 6일? 0:00 ora_s013_O901DB 0시 ora_s013_O901DB
  oracle 8740 1 0 Feb 06 ? 오라클 8740 1 0 2월 6일? 0:00 ora_s012_O901DB 0시 ora_s012_O901DB
  oracle 8720 1 0 Feb 06 ? 오라클 8720 1 0 2월 6일? 0:00 ora_s002_O901DB 0시 ora_s002_O901DB
  oracle 8724 1 0 Feb 06 ? 오라클 8724 1 0 2월 6일? 0:00 ora_s004_O901DB 0시 ora_s004_O901DB
  oracle 8716 1 0 Feb 06 ? 오라클 8716 1 0 2월 6일? 0:08 ora_s000_O901DB 0시 8분 ora_s000_O901DB
  oracle 8738 1 0 Feb 06 ? 오라클 8738 1 0 2월 6일? 0:00 ora_s011_O901DB 0시 ora_s011_O901DB
  oracle 8718 1 0 Feb 06 ? 오라클 8718 1 0 2월 6일? 0:06 ora_s001_O901DB 0시 6분 ora_s001_O901DB
  oracle 8728 1 0 Feb 06 ? 오라클 8728 1 0 2월 6일? 0:00 ora_s006_O901DB 0시 ora_s006_O901DB
  oracle 8736 1 0 Feb 06 ? 오라클 8736 1 0 2월 6일? 0:00 ora_s010_O901DB 0시 ora_s010_O901DB
  oracle 8722 1 0 Feb 06 ? 오라클 8722 1 0 2월 6일? 0:00 ora_s003_O901DB 0시 ora_s003_O901DB
  oracle 8744 1 0 Feb 06 ? 오라클 8744 1 0 2월 6일? 0:00 ora_s014_O901DB 0시 ora_s014_O901DB
  oracle 8726 1 0 Feb 06 ? 오라클 8726 1 0 2월 6일? 0:00 ora_s005_O901DB 0시 ora_s005_O901DB
  oracle 8730 1 0 Feb 06 ? 오라클 8730 1 0 2월 6일? 0:00 ora_s007_O901DB 0시 ora_s007_O901DB
  oracle 8734 1 0 Feb 06 ? 오라클 8734 1 0 2월 6일? 0:00 ora_s009_O901DB 0시 ora_s009_O901DB
  oracle 8732 1 0 Feb 06 ? 오라클 8732 1 0 2월 6일? 0:00 ora_s008_O901DB 0시 ora_s008_O901DB
  oracle 8746 1 0 Feb 06 ? 오라클 8746 1 0 2월 6일? 0:00 ora_s015_O901DB 0시 ora_s015_O901DB
  oracle 8748 1 0 Feb 06 ? 오라클 8748 1 0 2월 6일? 0:00 ora_s016_O901DB 0시 ora_s016_O901DB
  oracle 8750 1 0 Feb 06 ? 오라클 8750 1 0 2월 6일? 0:00 ora_s017_O901DB 0시 ora_s017_O901DB
  oracle 8752 1 0 Feb 06 ? 오라클 8752 1 0 2월 6일? 0:00 ora_s018_O901DB 0시 ora_s018_O901DB
  oracle 8754 1 0 Feb 06 ? 오라클 8754 1 0 2월 6일? 0:00 ora_s019_O901DB 0시 ora_s019_O901DB
  oracle 8756 1 0 Feb 06 ? 오라클 8756 1 0 2월 6일? 0:00 ora_s020_O901DB 0시 ora_s020_O901DB
  oracle 8758 1 0 Feb 06 ? 오라클 8758 1 0 2월 6일? 0:00 ora_s021_O901DB 0시 ora_s021_O901DB
  oracle 8760 1 0 Feb 06 ? 오라클 8760 1 0 2월 6일? 0:00 ora_s022_O901DB 0시 ora_s022_O901DB
  oracle 8762 1 0 Feb 06 ? 오라클 8762 1 0 2월 6일? 0:00 ora_s023_O901DB 0시 ora_s023_O901DB
  oracle 8764 1 0 Feb 06 ? 오라클 8764 1 0 2월 6일? 0:00 ora_s024_O901DB 0시 ora_s024_O901DB
  oracle 8766 1 0 Feb 06 ? 오라클 8766 1 0 2월 6일? 0:01 ora_d000_O901DB 0시 1분 ora_d000_O901DB
  oracle 8768 1 0 Feb 06 ? 오라클 8768 1 0 2월 6일? 0:02 ora_d001_O901DB 0시 2분 ora_d001_O901DB 

The above example shows two dispatcher processes as well as 25 shared server processes. 위 예제는 두 배차 프로세스뿐만 아니라 25 공유 서버 프로세스를 보여줍니다.

Listener Control 리스너 제어

Using the SERVICES command within the Listener Control utility, you can get a listing of the dispatchers that have been registered with the listener. 리스너 제어 유틸리티 내에서 서비스 명령을 사용하면 리스너에 등록되어있는 dispatchers의 목록을 얻을 수 있습니다. Here is a sample out of the SERVICES command: 여기 서비스 명령의 한 예제입니다 :

  LSNRCTL> SERVICES listener LSNRCTL> 서비스 청취자
  Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=cartman)(PORT=1526))) (= (ADDRESS = (PROTOCOL = TCP) (HOST = cartman) (PORT = 1526가)) 설명)은 연결
  Services Summary... 서비스 요약 ...
  Service "O901DB" has 1 instance(s). 서비스 "O901DB는"1 인스턴스 (들)을하고 있습니다.
    Instance "O901DB", status UNKNOWN, has 4 handler(s) for this service... 예를 들어 "O901DB"상태 알 수없는이 서비스에 대한 네 처리기 (들)을했습니다 ...
      Handler(s): 처리기 (들) :
        "DEDICATED" established:194 refused:0 "전용"설립 : 194 거절 : 0
           LOCAL SERVER 로컬 서버
        "DEDICATED" established:0 refused:0 state:ready "헌신"은 설립 : 0 거부 : 0 상태 : 준비
           LOCAL SERVER 로컬 서버
        "DISPATCHER" established:96 refused:23 current:38 max:250 state:ready 설립 "배차원"96 거부 : 23 현재 : 38 최대 : 250 상태 : 준비
           D000 D000 
           (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=1219)) () = (PROTOCOL = TCP) (HOST = cartman) (포트 = 1219을 주소)
  Service "PLSExtProc" has 1 instance(s). 서비스 "PLSExtProc"1 인스턴스 (들)을하고 있습니다.
    Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... 예를 들어 "PLSExtProc"상태 알 수없는이 서비스에 대해 1 처리기 (들)을했습니다 ...
      Handler(s): 처리기 (들) :
        "DEDICATED" established:0 refused:0 "전용"설립 : 0 거절 : 0
           LOCAL SERVER 로컬 서버
  The command completed successfully 명령이 성공적으로 완료 

Figure 4 (below) gives a short overview of the different parameters in the SERVICES output command. 그림 4는 (아래) 서비스 출력 명령에 다른 매개 변수의 짧은 개요를 제공합니다.

Figure 4: Output from the Listener Control's SERVICES command 그림 4 : 리스너 제어의 서비스 명령에서 출력

Dynamic Performance Views 동적 성능보기

Dynamic Performance View relevant to MTS MTS와 관련된 동적 성능보기
View name 이름보기	Description 설명
V$CIRCUIT V $ 회로	Returns one row to the instance for each MTS connection. 각각의 MTS 연결 인스턴스에 행 하나를 반환합니다. A circuit is a connection through a specific dispatcher and shared server process. 회로는 특정 배차 및 공유 서버 프로세스를 통해 연결됩니다. Columns in this view relate each MTS circuit to a specific dispatcher, shared server process and session. 이보기에서 열은 특정 배차, 공유 서버 프로세스와 세션에 각각의 MTS 회로 관련.
V$DISPATCHER V $의 배차	Returns one row for each dispatcher process associated with the instance. 인스턴스와 연관된 각 배차 프로세스를 하나의 행을 반환합니다. This view returns information such as the dispatcher's name, network address, process address and status. 이보기에는 배차의 이름, 네트워크 주소, 프로세스 주소 및 상태 등의 정보를 제공합니다.
V$DISPATCHER_RATE V $ DISPATCHER_RATE	Returns one row for each dispatcher process, and returns rate statistics for each dispatcher. 각 배차원 공정 한 행을 반환하고, 각각의 배차에 대한 비율 통계를 반환합니다.
V$MTS V $ MTS	Returns only one row. 하나의 행을 반환합니다. This view provides some statistics that you can use to determine whether or not you have the MTS_SERVERS parameter set to a reasonable value. 이보기는 당신이 적당한 값으로 MTS_SERVERS 매개 변수 집합이 있는지 여부를 확인하는 데 사용할 수있는 몇 가지 통계를 제공합니다.
V$QUEUE V $ 대기열	Returns one row for MTS queue in the instance. 인스턴스에 MTS 대기열에 대해 행 하나를 반환합니다. Each dispatcher will have one response queue associated with it, and their will always be one common request queue for the instance. 각 배차원는과 관련된 한 응답 대기열을 것입니다, 그들은 항상 인스턴스에 대해 하나 일반적인 요청 대기열 것입니다. The number of rows returned by V$QUEUE is always equal to the number of dispatchers plus one. V $ 대기열에 의해 반환된 행 수를 항상 dispatchers 더하기 하나의 숫자와 동일한 것입니다.
V$SHARED_SERVER V $ SHARED_SERVER	Returns one row for each shared server process that is currently running as part of the instance. 현재 인스턴스의 일부로 실행되는 각 공유 서버 프로세스에 대해 행 하나를 반환합니다. This view returns the process name, process address, status and other useful statistics. 이보기는 프로세스 이름, 프로세스 주소, 상태 및 기타 유용한 통계를 반환합니다.

Table 2: Dynamic Performance View relevant to MTS 표 2 : MTS와 관련된 동적 성능보기

Dispatcher Process Status 배차원 프로세스 상태

  SQL> SELECT name, status, accept, created, conf_indx, network SQL> SELECT 이름, 상태, 수락, 만든, conf_indx, 네트워크
    2 FROM v$dispatcher; V $ 배차원에서 2;

  NAME STATUS ACCEPT CREATED CONF_INDX NETWORK NAME 상태 만든 CON​​F_INDX 네트워크에 동의
  ---- ------ ------ ------- --------- -------------------------------------------------- ---- ------ ------ ------- --------- ------------------ --------------------------------
  D000 WAIT YES 56 0 (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=38793)) D000은 예 56 0 (= (PROTOCOL = TCP) (HOST = cartman) (포트 = 38793을 주소)) 기다려요
  D001 WAIT YES 78 1 (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=38794)) D001은 (주소 = (PROTOCOL = TCP) (HOST = cartman) (포트 = 38794)) YES 78 일 잠깐 

• NAME : Returns the dispatcher's name. 이름 : 배차의 이름을 반환합니다. This forms part of the operating system process name. 이것은 운영 체제 프로세스 이름의 일부를 형성합니다.

• NAME : Returns the dispatcher's current status. 이름 : 배차의 현재 상태를 반환합니다. Valid values are: 유효한 값은 다음과 같습니다
  • WAIT : The dispatcher is idle and waiting for work. WAIT : 배차원는 유휴 상태이고 일을 기다리고 있습니다.
  • SEND : The dispatcher is sending a message. 보내기 : 배차원는 메시지를 보내는 것입니다.
  • RECEIVE : The dispatcher is receiving a message. 수신 : 배차원는 메시지를 받고 있습니다.
  • CONNECT : The dispatcher is establishing a new connection from a client. 연결 : 배차원는 클라이언트에서 새 연결을 설정합니다.
  • DISCONNECT : A client is disconnecting from the dispatcher. 분리 : 클라이언트는 배차에서 분리됩니다.
  • BREAK : The dispatcher is handling a break. BREAK : 배차원는 휴식을 처리합니다.
  • OUTBOUND : The dispatcher is establishing an outbound connection. 아웃 바운드 : 배차원는 아웃 바운드 연결을 설정합니다.

• ACCEPT : Tells you whether or not the dispatcher is accepting new connections. 동의 : 배차가 새로운 연결을 수락할지 여부를 알려줍니다. Valid values are YES and NO. 유효한 값은 그렇기도하고 아니기도하지 않습니다.

• CREATED : Returns the number of virtual circuits currently associated with this dispatcher. 만든 : 현재이 배차와 관련된 가상 회로의 개수를 반환합니다.

• CONFIG IDX : Indicates the specific MTS_DISPATCHERS initialization parameter on which this dispatcher is based. CONFIG IDX :이 배차의 기반이되는 특정 MTS_DISPATCHERS 초기화 매개 변수를 나타냅니다. Dispatchers created from the first MTS_DISPATCHERS parameter in your instance's parameter file will have a CONF_INDX value of 0. 인스턴스의 매개 변수 파일의 첫 번째 MTS_DISPATCHERS 매개 변수에서 생성된 Dispatchers 0의 CONF_INDX 값이됩니다. Dispatcher's created from the second MTS_DISPATCHERS parameter will have a value of 1, and so on. 배차는 두 번째 MTS_DISPATCHERS 매개 변수에서 이렇게 1의 값을 가지고 있고, 만들어지는 것입니다.

• NETWORK : Returns the dispatcher's network address. 네트워크 : 배차의 네트워크 주소를 반환합니다.

Dispatcher Process Utilization 배차원 프로세스 활용

  SQL> SELECT name, busy / (busy + idle) * 100 SQL> SELECT 이름, (바쁜 + 유휴) / 바쁜 * 100
    2 FROM v$dispatcher; V $ 배차원에서 2;

  NAME BUSY/(BUSY+IDLE)*100 이름 (바쁜 + 유휴) / 바쁜 * 100
  ---- -------------------- ---- --------------------
  D000 .000359889 D000 0.000359889
  D001 .000405469 D001 0.000405469 

Doesn't look like these dispatchers are very busy! 이러한 dispatchers 매우 바쁘다처럼 보이지 않는다! Keep in mind that the BUSY and IDLE values are reported in hundredths of a second. 바쁜와 유휴 값이 두 번째의 hundredths에서보고 있음을 유념하시기 바랍니다. If the BUSY value for a dispatcher is 100, that means the dispatcher had been busy for 1 second. 배차에 대한 약속 값이 100면, 그것은 배차 1 초 동안 바쁜 있었다는 것이죠.

If dispatcher utilization is very high, you should consider creating more dispatcher processes. 배차 사용률이 매우 높은 경우 더 배차 프로세스를 만드는 것이 좋습니다. If dispatcher utilization is very low, you should consider deleting some dispatcher processes. 배차 사용률이 매우 낮은 경우, 일부 배차 프로세스를 삭제 고려해야합니다. In the above example, I would consider only running one dispatcher process to support this instance. 위의 예제에서, 난 단지이 인스턴스를 지원하는 하나의 배차 프로세스를 실행이라고 생각한다.

Queue Size and Wait Time 대기열 크기와 대기 시간

  SQL> SELECT paddr, type, queued, DECODE(totalq,0,0,wait/totalq) SQL> SELECT paddr, 종류, 대기열, 디코딩 (totalq, 0,0, 잠깐 만요 / totalq)
    2 FROM v$queue; V $ 대기열에서 2;

  PADDR TYPE QUEUED DECODE(TOTALQ,0,0,WAIT/TOTALQ) PADDR 종류 대기열 해독 (TOTALQ, 0,0, 기다려 / TOTALQ)
  -------- ---------- -------- ------------------------------ -------- ---------- -------- ------------------------ ------
  00 COMMON 0 .009878904 00 공통 0 0.009878904
  8008AC54 DISPATCHER 0 3.38482683 8008AC54 배차원 0 3.38482683
  8008AF70 DISPATCHER 0 .009591116 8008AF70 배차원 0 0.009591116 

You can get an idea of how well work is flowing through the request and response queues by using v$queue. 이 작품은 V $ 대기열을 사용하여 요청 및 응답 대기열을 통해 흐르는 얼마나 잘의 아이디어를 얻을 수 있습니다.

The DECODE in the query handles the case where the TOTALQ column, which is the divisor, happens to be zero. 검색어에 디코딩은 제수입니다 TOTALQ 열에, 제로에서 일어나는 사건을 처리합니다. The average wait time is reported in hundredths of a second. 평균 대기 시간은 초 hundredths에보고됩니다. (ie If the average wait time of a dispatcher is 37, works out to 0.37 seconds.) (즉 배차의 평균 대기 시간은 37 경우 0.37 초로 사용할 수 있습니다.)

The COMMON queue is where requests are placed so that they can be picked up and executed by a shared server process. 요청들이 데리러와 공유 서버 프로세스에 의해 실행될 수 있도록 배치 어디 공통 대기열입니다. If you average wait time is high, you might be able to lower it by creating more shared server processes. 기다리는 시간 높은 평균되면 더 많은 공유 서버 프로세스를 생성하여 그것을 낮출 수 있습니다.

Users and Dispatchers 사용자 및 Dispatchers

  SQL> SELECT d.name, s.username, c.status, c.queue SQL> SELECT d.name, s.username, c.status, c.queue
    2 FROM v$circuit c, v$dispatcher d, v$session s
    3 WHERE c.dispatcher = d.paddr AND c.saddr = s.saddr;

  NAME USERNAME STATUS QUEUE
  ---- ------------------ ---------------- ----------------
  D000 JHUNTER NORMAL NONE
  D001 AHUNTER NORMAL NONE 

• NAME : Returns the dispatcher's name. This forms part of the operating system process name.

• USERNAME : Oracle username.

• STATUS : Reports the status of the circuit, and may take one of the following values:
  • BREAK : The circuit had been interrupted due to a break.
  • EOF : The connection is terminating, and teh circuit is about to be deleted.
  • OUTBOUND : The circuit represents an outbound connection to another database.
  • NORMAL : The circuit represents a normal client connection.

• QUEUE : Reports on the work currently being done. One the following values will be returned:
  • COMMON : A request has been placed into the common request queue, and the circuit is waiting for it to be picked up be a shared server process.
  • DISPATCHER : Results from a request are being returned to the client by the dispatcher.
  • SERVER : A request is currently being acted upon by a shared server process.
  • NONE : A circuit (or connection) is idle. Nothing is happening.

Shared Server Utilization

 SQL> SELECT name, busy / (busy + idle) * 100
    2 FROM v$shared_server;

  NAME BUSY/(BUSY+IDLE)*100
  ---- -------------------- ---- --------------------
  S000 .00155527
  S001 .000669656
  S002 .000012313
  S003 0
  S004 0
  S005 0
  S006 0
  S007 0
  S008 0
  S009 0
  S010 0
  S011 0
  S012 0
  S013 0
  S014 0
  S015 0
  S016 0
  S017 0
  S018 0
  S019 0
  S020 0
  S021 0
  S022 0
  S023 0
  S024 0 

Other Shared Server Statistics

The v$mts view is useful when trying to tune both the MTS_SERVERS and MTS_MAX_SERVERS initialization parameters. Here is an example output from v$mts:

 SQL> SELECT servers_started, servers_terminated, servers_highwater
    2 FROM v$mts;

  SERVERS_STARTED SERVERS_TERMINATED SERVERS_HIGHWATER
  --------------- ------------------ -----------------
               94 18 25 

• SERVERS_STARTED : The number of shared server processes started as the instance adjusts the number of shared processes up and down from the initial value specified by the MTS_SERVERS parameter. When the instance starts, and after the initial number of shared server processes specified by MTS_SERVERS has been started, this value is set to 0. From that point on, this value is incremented whenever a new shared server process is started.

• SERVERS_TERMINATED : A count of the total number of shared server processes that have been terminated since the instance was started.

• NOTES : If the SERVERS_HIGHWATER value matches, the instance's MTS_MAX_SERVERS value, then you might realize a performance benefit from increasing MTS_MAX_SERVERS. If the counts for SERVERS_STARTED and SERVERS_TERMINATED keep climbing, then you should consider raising MTS_SERVERS. Raising the minimum number of shared server processes should reduce the number that are deleted only to be recreated later.

[CRS, DB PATCHSET 한 후  DB만 원래대로 복원하기 위해 downgrade를 해줌]

전제조건
   1. 10.2.0.5 patchset으로 설치된 crs 와 db 설치됨
   2. 10.2.0.4 버전이었을때 백업을 해놓아야하는 부분(oraInventory, ORACLE_HOME폴더)
      2-1. /etc/oraInst.loc에 내용에 있는 oraInventory 폴더
      2-2. ORACLE_HOME 폴더

1. crs_stat -t   RAC상태가 online인지 확인한다.

2. alter system set cluster_database=FALSE scope=spfile;

3. srvctl stop database -d DB명 후
   
   $ORACLE_HOME/rdbms/admin/catrelod.sql
   $ORACLE_HOME/network/admin/tnsnames.ora
  
   위 두개 파일을 백업 해놓는다.

4.
   4-1. sqlplus 접속후
   4-2. startup downgrade
   4-3. spool downgrade.out
   4-4. @?/rdbms/admin/catdwgrd.sql
   4-5. spool off
   4-6. shutdown immediate

5. 10.2.0.4버전이었을때 백업했던 oraInventory폴더를   /etc/oraInst.loc 파일에서 가르키고 있는 곳에 복원 시킴

6. 10.2.0.4버전이었을때 백업했던 것을 다시 복원시켜야함
   6-1. 위에서 백업했던 10.2.0.5용 catrelod.sql와 tnsnames.ora를  10.2.0.4폴더 자리에 넣어놓는다.

7. 한쪽노드에서
   7-1. sqlplus 접속후
   7-2. startup downgrade
   7-3. spool catrelod.out
   7-4. @?/rdbms/admin/catrelod.sql
   7-5. spool off
   7-6. select comp_name, version, status from dba_registry;
        COMP_NAME                           VERSION                        STATUS
        ----------------------------------- ------------------------------ ----------------------
        Oracle Enterprise Manager           10.2.0.4.0                     VALID
        Spatial                             10.2.0.4.0                     INVALID
        Oracle interMedia                   10.2.0.4.0                     VALID
        OLAP Catalog                        10.2.0.4.0                     VALID
        Oracle XML Database                 10.2.0.4.0                     VALID
        Oracle Text                         10.2.0.4.0                     VALID
        Oracle Expression Filter            10.2.0.4.0                     VALID
        Oracle Rule Manager                 10.2.0.4.0                     VALID
        Oracle Workspace Manager            10.2.0.4.3                     VALID
        Oracle Data Mining                  10.2.0.4.0                     VALID
        Oracle Database Catalog Views       10.2.0.4.0                     VALID
        Oracle Database Packages and Types  10.2.0.4.0                     VALID
        JServer JAVA Virtual Machine        10.2.0.4.0                     VALID
        Oracle XDK                          10.2.0.4.0                     VALID
        Oracle Database Java Packages       10.2.0.4.0                     VALID
        OLAP Analytic Workspace             10.2.0.4.0                     VALID
        Oracle OLAP API                     10.2.0.4.0                     INVALID
        Oracle Real Application Clusters    10.2.0.4.0                     VALID

   7-7. shutdown immediate
   7-8. startup
   7-9. @?/rdbms/admin/utlrp.sql
  
8. select comp_name, version, status from dba_registry;
   COMP_NAME                           VERSION                        STATUS
   ----------------------------------- ------------------------------ ----------------------
   Oracle Enterprise Manager           10.2.0.4.0                     VALID
   Spatial                             10.2.0.4.0                     VALID
   Oracle interMedia                   10.2.0.4.0                     VALID
   OLAP Catalog                        10.2.0.4.0                     VALID
   Oracle XML Database                 10.2.0.4.0                     VALID
   Oracle Text                         10.2.0.4.0                     VALID
   Oracle Expression Filter            10.2.0.4.0                     VALID
   Oracle Rule Manager                 10.2.0.4.0                     VALID
   Oracle Workspace Manager            10.2.0.4.3                     VALID
   Oracle Data Mining                  10.2.0.4.0                     VALID
   Oracle Database Catalog Views       10.2.0.4.0                     VALID
   Oracle Database Packages and Types  10.2.0.4.0                     VALID
   JServer JAVA Virtual Machine        10.2.0.4.0                     VALID
   Oracle XDK                          10.2.0.4.0                     VALID
   Oracle Database Java Packages       10.2.0.4.0                     VALID
   OLAP Analytic Workspace             10.2.0.4.0                     VALID
   Oracle OLAP API                     10.2.0.4.0                     VALID
   Oracle Real Application Clusters    10.2.0.4.0                     VALID

9. alter system set cluster_database=TRUE scope=spfile;
10. shutdown
11. srvctl start database -d 데이터베이스명

■ Share pool과 성능문제

 

  xx지원 오라클 장애처리
  ========================
  작성자 :

   1. 장애처리
      장애 시간 : 2006-07-21 11:34
      장애 서버 : xx지원 서버2의 오라클 데이터베이스
      장애 유형 : 오라클 데이터베이스 인스턴스 다운
      장애 원인 : 오라클의 LMD(LOCK MONITOR DEADON) 다운으로 오라클 인스턴스 다운이 발생함
                  (장애분석 참조)
      장애 조치 : 오라클 인스턴스 재시작함
      복구 시간 : 2006-07-21 11:53
      장애 예방방안 : 장애대처 예방 참조

   2. 장애분석
     [ alert! 로그 파일]
       Fri Jul 21 11:34:26 2006                      ==> 장애 시간
       LMD0: terminating instance due to error 4031  ==> 장애 메시지
       Instance terminated by LMD0, pid = 19848      ==> 데이터베이스 다운

     [ trace 파일 분석 ]
      파일명 : llmd0_19848_hiraops2.trc
       *** 2006-07-21 11:34:26.346
       *** SESSION ID:(3.1) 2006-07-21 11:34:26.306
       error 4031 detected in background process
    
     [ 장애원인 ]
       ORA-4031 : shared pool memory 분석으로 LMD 프로세스 다운으로 발생함
       Shared Pool의 정확인 영역은 나타나지 않음

       <참조 : 메시지 >
       04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"
       *Cause:  More shared memory is needed than was allocated in the shared pool.
       *Action: If the shared pool is out of memory, either use the dbms_shared_pool package to pin
                large packages,reduce your use of shared memory, or increase the amount of available shared
                memory by increasing the value of the INIT.ORA parameters "shared_pool_reserved_size" and
                "shared_pool_size".
                If the large pool is out of memory, increase the INIT.ORA parameter "large_pool_size".

       < Ora-4031 란 ? >
        이 에러는 사용자가 특정 Object를 사용하고자 할 때 해당 Object를 위해 Shared_Pool에 공간을 할당하려 할 때 충분한
        공간을 얻지 못하는 경우이다
        Shared_Pool 영역에 차지하는 크기가 큰 PL/SQL 사용시 오라클은 공간 확보를 위해 현재 사용되지 않는 Object를 Flush시킨다.
        기존 V7.2. 이하에서는 특정 프로시저를 Shared_Pool에 올리기 위해 연속된 공간을 필요로 하였으나, 이후 버전에
       서는 꼭 연속되지 않아도 사용이 가능하여 ORA-4031 에러가 발생하는 경우가 많이줄어들었다.
        이의 해결을 위해서는 Shared_Pool을 늘려주도록 한다 .
        이 에러를 유발시키는 문제인 메모리의 단편화 (fragmentation)를 줄이기 위해서, 또는 일반적인 경우 자주 사용하는 Object가
        메모리에서 밀려 내려가는 경우를 없애기 위해서 Object를 미리 Shared_Pool에  Keep 한다.

   3.장애 예방 방안
    [ 목적 ]
     - Shared Pool Memory 부족(ORA-4031) 장애발생 예방

    [ 예방 방법 ]
     - shared pool size , shared pool reserved size , large pool size를 증가 한다.
    
    [ Shared Pool Memory 할당 값]
      #shared_pool_size              = 471859200             # 450MB
      #shared_pool_reserved_size     = 47185920              # shared pool * 10%
      #shared_pool_size              = 512000000             # 500MB             2005.07.21
      #shared_pool_reserved_size     = 51200000              # shared pool * 10% 2005.07.21
 
       shared_pool_size               = 629145600              # 600MB             2005.08.08
       shared_pool_reserved_size      = 62914560               # shared pool * 10% 2005.08.08
       java_pool_size                = 2097152
       large_pool_size               = 10M                   # 2004/10/30

    [ 메모리 사용률 ]
      전체 메모리 : 19.9G  
      사용률 : Sys Mem  : 4.68GB   User Mem:  2.71GB   Buf Cache: 1.99GB   Free Mem: 10.5GB

    [ shared pool free memory 확인 QUERY 및 flush 명령어]
  
    SQL> select v$sgastat.pool, to_number(v$parameter.value) value, v$sgastat.bytes,
          (v$sgastat.bytes/v$parameter.value)*100 "Percent Free"
          from v$sgastat , v$parameter
          where v$sgastat.name = 'free memory'
          and v$parameter.name = 'shared_pool_size';

          POOL          VALUE          BYTES   Percent Free
         ---------------------------------------------------------------
         shared pool 629145600 140415416 22.3184293111165   <-- free space 확인
         large pool 629145600 299984         0.0476811726888021
         java pool 629145600 2097152         0.333333333333333

    SQL> alter system flush shared_pool;   <-- 단편화된 조각화를 flush 해주는 방법(메모리 조각모음) (업무외시간에 수행)

 

    [ Library Cache Fragmentation 확인 Query]

         select
             decode(sign(ksmchsiz - 812), -1, (ksmchsiz - 16) / 4,
               decode(sign(ksmchsiz - 4012), -1, trunc((ksmchsiz + 11924) / 64),
                 decode(sign(ksmchsiz - 65548), -1, trunc(1/log(ksmchsiz - 11, 2)) + 238, 254 )))  bucket,
             sum(ksmchsiz)  free_space,  count(*)  free_chunks,  trunc(avg(ksmchsiz))  average_size,
             max(ksmchsiz)  biggest
           from
             sys.xm$ksmsp
           where
             inst_id = userenv('Instance') and  ksmchcls = 'free'
           group by
             decode(sign(ksmchsiz - 812), -1, (ksmchsiz - 16) / 4,
               decode(sign(ksmchsiz - 4012),-1, trunc((ksmchsiz + 11924) / 64),
                 decode(sign(ksmchsiz - 65548),-1, trunc(1/log(ksmchsiz - 11, 2)) + 238, 254)))

           BUCKET FREE_SPACE FREE_CHUNKS AVERAGE_SIZE    BIGGEST
           ---------- ---------- ----------- ------------ -------------------------------------------------------
                    6       92000         2300         40         40
                    8       1392          29           48         48
                   10       1456          26           56         56
           ……
           위의 결과처럼 shared pool 영역에 작은 chunk 들의 다수 존재하는 경우에는 free list   검색시 shared pool latch를 장시간 holding하게 되며,
           이는 shared pool latch free 대기 현상이 발생할 가능성을 높여주게 된다. 일반적으로 hard parsing에 의해 이러한 현상들이 발생하게 됨.
          
          
           
          
     [ Shared Pool size 적절성 확인 Query ]
         
                                                     
           column kghlurcr heading "RECURRENT|CHUNKS"
           column kghlutrn heading "TRANSIENT|CHUNKS"
           column kghlufsh heading "FLUSHED|CHUNKS"  
           column kghluops heading "PINS AND|RELEASES"
           column kghlunfu heading "ORA-4031|ERRORS" 
           column kghlunfs heading "LAST ERROR|SIZE" 
          
           select
             kghlurcr "RECURRENT|CHUNKS" ,
              kghlurcr *3,
             kghlutrn "TRANSIENT|CHUNKS" ,
             kghlufsh "FLUSHED|CHUNKS"  ,
             kghluops "PINS AND|RELEASES" ,
             (kghlufsh/ kghluops) *100,
             kghlunfu "ORA-4031|ERRORS" ,
             kghlunfs "LAST ERROR|SIZE"
           from
             sys.x_$kghlu
           where
           inst_id = userenv('Instance');

          
           RECURRENT  TRANSIENT    FLUSHED        PINS AND    ORA-4031 LAST ERROR
               CHUNKS     CHUNKS     CHUNKS        RELEASES     ERRORS       SIZE
           ---------- ---------- ---------------  ---------- -----------------------------------------------------------------
                  587       1687          8946       28416904          0          0
                 

--  일반적으로 Transient list가 Recurrent List 의 3배 이상이면 shared pool 이 oversize  된 것이며, chunk flush 수치가
  --         pins and released 수치의 5% 이상이면 shared pool 이 작게 설정된 것이라고 볼 수 있다.
          

 

 

shared pool 의 free 공간 확인

 

 

select to_number(v$parameter.value) value, v$sgastat.bytes,
(v$sgastat.bytes/v$parameter.value)*100 "Percent Free"
from v$sgastat, v$parameter
where v$sgastat.name = 'free memory'
and v$parameter.name = 'shared_pool_size';

 

 

■ Shared Pool 관련 wait

 

Latch	Lock
latch free ( library cache ) latch free ( library cache load lock)	library cache lock, library cache pin library cache load lock
latch free ( row cache objects )	row cache lock
latch free ( shared pool )

 

 

☞   4-6 library cache 알고리즘

 

라이브러리 캐쉬는 lru 알고리즘에의해 관리가 되며

문장이 이미 캐쉬에 저장되어 있는가를 찾기 위하여, 오라클 서버는 다음을 수행합니다:

 

1. ASCII 텍스트의 수치로 문장을 줄임
2. 이 수치에 해시 함수 사용

 

 

☞   4-7  shared pool latch 

 

SQL 이 공유되지 못하고 파싱해달라고 하는 SQL 이 많아지면 공간을 할당 받아야하는데 이때
공간을 할당 받을때 메모리에 락(latch) 를 건다. latch 를 사용하는 이유는 파싱해달라고 요청하는
sql 에 대하여 순서를 정하는 것인데 먼저 요청한 sql 에 대하여 작업을 원할히 수행하기 위해 메모리에 락을 거는것이다.즉 동시 엑세스를 제어하기 위해 latch 를 사용한다.

그런데 조각화(단편화) 가 심해지면 free list 가 그만큼 길어지므로 공간 할당받을때 시간이 많이 소유될것이고 이로 인해 발생하는 wait event ( latch free(library cache) ) 가 다량으로 발생할것이다.

이를 해결하기 위해서는

 

1. 바인드변수 사용
2. cursor_sharing 사용
3.  shared pool size 늘린다.
4. large pool 을 구성한다.

 

☞   4-8  shared pool 에 공유되지 않은 SQL 에 대한 정보 보기

select  *
 from v$sqlarea
 where executions < 5
  order by upper(sql_Text)
 
 
select sql_Text, parse_calls, executions
   from v$sqlarea
     order by parse_calls; 

 

☞   4-12 ~            실습

v$sqlarea

(라이브러리 캐쉬: 문장저장)

동일한 문장

1. 대소문자
2. 스키마(schema)
3. 공백
4. 주석
5. bind 변수의 type(아래설명)

*****************************************
scott1
실행
 SQL> select empno,ename from emp where deptno=10;

      EMPNO ENAME
 ---------- ----------
       7782 CLARK
       7839 KING
       7934 MILLER

internal에서 실행
 SQL> ed
 Wrote file afiedt.buf

      select sql_text,SHARABLE_MEM,EXECUTIONS
      from v$sqlarea
     where sql_text like 'select empno,ename from emp where%';
  

 SQL_TEXT     SHARABLE_MEM  EXECUTIONS
 -------------------------------------------------------------- ----------
 select empno,ename from emp where deptno=10             5234   1
 
 사용했던 문장이 나옴

scott1
변수 선언
 SQL> variable v1 varchar2(10)
 SQL> declare
   2  begin
   3     :v1 := '10';
   4  end;
   5  /

 PL/SQL procedure successfully completed.

 SQL> select empno, ename from emp where deptno=:v1;

      EMPNO ENAME
 ---------- ----------
       7782 CLARK
       7839 KING
       7934 MILLER

internal
 SQL> /

 SQL_TEXT                                           SHARABLE_MEM EXECUTIONS
 -------------------------------------------------- ------------ ----------
 select empno,ename from emp where deptno=10                5234          1
 select empno,ename from emp where deptno=:v1               5067          1

scott1
변수값을 바꾸어줌
 SQL> declare
   2  begin
   3     :v1 := '20';
   4  end;
   5  /

 PL/SQL procedure successfully completed.

 SQL> select empno,ename from emp where deptno=:v1;

      EMPNO ENAME
 ---------- ----------
       7369 SMITH
       7566 JONES
       7788 SCOTT
       7876 ADAMS
       7902 FORD

internal
scott의 결과는 달라도 새로 파싱을 안함
 SQL> /

 SQL_TEXT                                           SHARABLE_MEM EXECUTIONS
 -------------------------------------------------- ------------ ----------
 select empno,ename from emp where deptno=10                5234          1
 select empno,ename from emp where deptno=:v1               5067          2

 

문제) select empno,ename from emp where deptno=30 을 하고 출력해보아라 !!!  

   
scott2

변수형을 넘버로 선언
 SQL> variable v1 number
 SQL>  declare
    2  begin
    3  :v1 :=20;
    4  end;
 PL/SQL procedure successfully completed.

 SQL> select empno,ename from emp where deptno=:v1;

      EMPNO ENAME
 ---------- ----------
       7369 SMITH
       7566 JONES
       7788 SCOTT
       7876 ADAMS
       7902 FORD

internal

scott2에 실행한 문장후 크기가 늘어남 (파싱계획변경)
 SQL> /

 SQL_TEXT                                           SHARABLE_MEM EXECUTIONS
 -------------------------------------------------- ------------ ----------
 select empno,ename from emp where deptno=10                5234          1
 select empno,ename from emp where deptno=:v1               8939          3

 

********** bind type에 따라 파싱이 다르다 ****************

 

 

☞   4-13           실습

1) v$librarycache 를 통해 hit율(gethitratio)를 분석

   - gets    : 사용자가 실행한 SQL문이 구문 분석되어 라이브러리 캐시 영역에 로드되려 했던 수.
   - gethits : 그 중 로드되었던 수
   - hit율(gethitratio)이 90% 이상일때 좋은 성능 기대

select namespace , gets , gethits,gethitratio
from v$librarycache
where namespace = 'SQL AREA' ;

NAMESPACE         GETS    GETHITS GETHITRATIO
--------------- ---------- ---------- -----------
SQL AREA            141767     141498     .99810252

  <= GETHITRATIO 컬럼 값이 90%이상이면 라이브러리 캐시 영역이 개발자들의 SQL 파싱정보를
      저장하기에 충분한 메모리 공간을 확보하고 있슴을 의미하며, 만약 90% 이하라면 성능이 저하
      될 수 있다는 것을 의미.
      물론 90% 이하라도 사용자들이 성능에 만족한다면 튜닝 대상이 안될 수도 있으며 반드시 튜닝
      을 해야 할 필요는 없다.

  ▷ 유의사항
     - 히트율 분석은 기업에서 가장 일을 바쁘게 진행하고 있는 시간대의 분석 결과를 기준으로
        하여야 한다.

  ▷ 초치사항
     - HIT율이 90% 이하일 경우 SHARED_POOL_SIZE 파라메터 값을 높게 설정.
    ex) initSID.ora
               ......
          SHARED_POOL_SIZE = 32000000  <= 이전 보다 큰 값으로 변경
              .....
    
2) v$library 자료사전을 통해 RELOAD 비율 분석.

   - RELOADS 비율  =  ( Reloads / Pins ) * 100
   - Library Cache Area 의 크기가 너무 작아서 사용자의 SQL 구문분석 정보가 로드되지 못하고
     가장 오래된 SQL문 정보를 삭제 후 사용자의 SQL 문장이 다시 실행될 때 Reloads 증가.
  - 구분분석된 SQL문에서 사용된 객체가 다른 사용자에 의해 삭제된 상태에서 다시 SQL문이
     재실행될 때에는 RELOADS 컬럼값이 증가.
  - PINS : 구문분석되어 Library Cache Area 에 저장될 수 있었던 SQL 정보.
  - PINS 컬럼에 대한 Realods 컬럼의 백분율이 1% 미만일 때 좋은 성능 기대.

select sum(pins),sum(reloads),sum(reloads)/sum(pins)
from v$librarycache
where namespace = 'SQL AREA' ;

SUM(PINS) SUM(RELOADS) SUM(RELOADS)/SUM(PINS)
----------      ------------     ----------------------
    320823            10                   .00003117
  
<= PINS에 대한 RELOADS의 비율이 1% 미만일 때 라이브러리 캐시 영역의 크기가 AQL 파싱정보
     를 저장하기에 충분하다는 것을 의미. 1% 이상이라면 성능이 저하될 수도 있다는 것을 의미.

3) v$librarycache 를 통해 SQL문에서 사용된 객체가 다른 사용자들에 의해 얼마나 자주
     삭제,변경되었는 지를 분석하는 방법.
    주로 ANALYZE ,ALTER , DROP명령어에 의해 테이블 구조가 변경되는 경우에 발생.

select namespace, invalidations
from v$librarycache
where namespace = 'SQL AREA' ;

NAMESPACE       INVALIDATIONS
--------------- -------------
SQL AREA                    0

  <= INVALIDATIONS 컬럼의 값이 높게 출력 되거나 계속적으로 증가 값을 보인다면 공유 풀 영역
     에 작아서 성능이 저하되도 있음을 의미. 즉, 불필요한 재파싱. 재로딩 작업이 발생할 가능성이 높
     아지는 것이다.

 

 

 

☞   4-14 ~            실습

SQL> alter system set cursor_sharing=force scope=both;

시스템이 변경되었습니다.

SQL>
SQL>
SQL> select sql_text,SHARABLE_MEM,EXECUTIONS
           from v$sqlarea
          where sql_text like 'select empno,ename from emp where%';

SQL_TEXT
--------------------------------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=10
        6693          1

select empno,ename from emp where deptno=30
        6725          1

select empno,ename from emp where deptno=:v1
        6546          1

SQL> alter system flush shared_pool;

 

시스템이 변경되었습니다.

 

SQL> select sql_text,SHARABLE_MEM,EXECUTIONS
  2        from v$sqlarea
  3       where sql_text like 'select empno,ename from emp where%';

 

SQL_TEXT
--------------------------------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=30
        1461          0

 

scott 창에서

SQL> select empno,ename from emp where deptno=10;

SQL> /

SQL_TEXT
--------------------------------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=30
        1461          0

select empno,ename from emp where deptno=:"SYS_B_0"
       11873          1

scott 창에서

SQL> select empno,ename from emp where deptno=20;

SQL> /

SQL_TEXT
--------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=30
        1461          0

select empno,ename from emp where deptno=:"SYS_B_0"
       11873          1

문제) 다시 exact   로 바꾸고 실습하여라 !!!

SQL> alter system set cursor_Sharing=exact;

 

시스템이 변경되었습니다.

SQL> select sql_text,SHARABLE_MEM,EXECUTIONS
  2             from v$sqlarea
  3            where sql_text like 'select empno,ename from emp wh

 

SQL_TEXT
------------------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=10
        6705          1

select empno,ename from emp where deptno=30
        1461          0

select empno,ename from emp where deptno=:"SYS_B_0"
       11873          2

SQL>
SQL> /

 

SQL_TEXT
------------------------------------------------------------------
SHARABLE_MEM EXECUTIONS
------------ ----------
select empno,ename from emp where deptno=10
        6705          1

select empno,ename from emp where deptno=20
        6725          1

select empno,ename from emp where deptno=30
        1461          0

select empno,ename from emp where deptno=:"SYS_B_0"
       11873          2

 

☞   4-17           실습

 

****************  테이블과 뷰만들어서 파싱확인하기 ****************

scott1
테이블 생성 및 뷰 생성
 SQL> create table abc
   2  (a1 number, a2 number);

 Table created.

 SQL> insert into abc values(111,111);

 1 row created.

 SQL> commit;

 Commit complete.

 SQL> create view abcvw
   2  as
   3  select a1+a2 summun
   4  from abc;

 View created.

scott2
테이블 뷰 실행
 SQL> select * from abcvw;

     SUMMUN
 ----------
        222

scott1
테이블 드랍
 SQL> drop table abc;

 Table dropped.

internal
 SQL> ed
 Wrote file afiedt.buf

   1  select sql_text,SHARABLE_MEM,EXECUTIONS, INVALIDATIONS
   2  from v$sqlarea
   3* where sql_text like 'select * from abcvw%'
 SQL> /

 SQL_TEXT                            SHARABLE_MEM EXECUTIONS INVALIDATIONS
 ----------------------------------------------- -----------------------
 select * from abcvw   866     1           1

scott2
테이블 뷰 쿼리
 SQL> select * from abcvw;
 select * from abcvw
        *
 ERROR at line 1:
 ORA-04063: view "SCOTT.ABCVW" has errors

scott1
다시 테이블 생성
 SQL> create table abc
   2  (a1 number, a2 number);

 Table created.

 SQL> insert into abc values(111,111);

 1 row created.

 SQL> commit;

 Commit complete.

scott2
뷰 실행(다시 실행이 됨)
 SQL> select * from abcvw;

     SUMMUN
 ----------
        222

internal

 SQL> /

 SQL_TEXT                            SHARABLE_MEM EXECUTIONS INVALIDATIONS
 ----------------------------------- ------------ ---------- -------------
 select * from abcvw                         5718          2             1

 

☞   4-20            실습

 

select shared_pool_size_for_estimate as pool_size, estd_lc_size, estd_lc_time_saved
   from v$shared_pool_advice;

 

 

SHARED_POOL_SIZE_FOR_ESTIMATE NUMBER :   Shared pool size for the estimate (in megabytes)

 

ESTD_LC_SIZE NUMBER:        Estimated memory in use by the library cache (in megabytes)

 

ESTD_LC_TIME_SAVED NUMBER

 

Estimated elapsed parse time saved (in seconds), owing to library cache memory objects being found in a shared pool of the specified size. This is the time that would have been spent in reloading the required objects in the shared pool had they been aged out due to insufficient amount of available free memory

 

☞   4-25       실습

 

■ V$SQL_PLAN

- Oracle9i 부터 새롭게 추가된 기능
- SQL문이 실행되면서 작성된 실행계획이 Shared Pool Area에 저장됨.

SQL>connect system/manager
SQL>grant dba to scott ;
SQL>connect scott/tiger
SQL>select * from dept ;
SQL>select sql_text , hash_value , address
        from v$sqlarea ;

SQL_TEXT            HASH_VALUE ADDRESS
------------------- ---------- ----------
select * from dept     3015709834   04165C60

SQL>select id, lpad(' ',depth)||operation operation , options , object_name,optimizer,cost
        from v$sql_plan
        where hash_value = &1 and address='&2'
        start with id=0
        connect by ( prior id = parent_id and prior hash_value = hash_value
                     and prior_child_number = child_number)
        order  siblings by id, position;

       &1 :  3015709834 (HASH_VALUE )
       &2 :  04165C60   (ADDRESS)

   ID     OPERATION                  OPTIONS   OBJECT_NAME    OPT    COST
  ----  ----------------------  ----------- ---------------   ------   ------
   0      SELECT STATEMENT                                              CHO
   1     TABLE ACCESS              FULL            DEPT


  <=  또는, set autotrace on 사용으로 SQL문 실행시 파싱단계에서 옵티마이저가 작성한 실행계획
        을 참조할 수 있다.

 

 

 

☞   4- 26 실습

 

SQL> show parameter shared_pool_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
shared_pool_size                     big integer 50331648

 

SQL> select sum(sharable_mem)
       from  v$db_object_cache;

 

SUM(SHARABLE_MEM)
-----------------
           331406

☞   4-30 ~ 4-32           실습

 

 show parameter shared

 

select p.value/r.value * 100 "reserved radit"
     from v$parameter p, v$parameter r
     where p.name = 'shared_pool_reserved_size'
    and r.name = 'shared_pool_size';

 

select * from v$db_object_cache
 where sharable_mem  > 10000
 and ( type='PACKAGE' or  type='PACKAGE BODY' or
          type='FUNCTION' or type='PROCEDURE' )
and kept='NO';

@d:\oracle\ora92\rdbms\admin\dbmspool.sql

 

 desc dbms_shared_pool

 

 execute dbms_shared_pool.keep('dbms_sql');

 

select * from v$db_object_cache
 where sharable_mem  > 10000
 and ( type='PACKAGE' or  type='PACKAGE BODY' or
          type='FUNCTION' or type='PROCEDURE' )

 

☞   4-30 ~ 4-32           실습

 

SQL> declare x number;
      begin x :=5;
     end;
     /

PL/SQL 처리가 정상적으로 완료되었습니다.

SQL>
SQL> declare /* keep_me */ x number;
     begin x := 5;
     end;
     /

PL/SQL 처리가 정상적으로 완료되었습니다.

SQL> select address, hash_value
      from v$sqlarea
      where command_type=47
      and sql_Text like '%keep_me%';

ADDRESS  HASH_VALUE
-------- ----------
669841E4 4215866029

 execute dbms_shared_pool.keep('669841E4,4215866029','c');

select distinct name, sharable_mem, loads
     from v$db_object_cache
   where name like '%keep_me%';

 

DBMS_SHARED_POOL을 이용한 KEEP

 

Shared Poll에 크기가 큰 프로그램을 KEEP하기 위해서는 아래에 있는 것처럼 DBMS_SHARED_POOL Package를 이용 할 수 있습니다.

 

SQL> @C:\oracle\ora92\rdbms\admin\dbmspool.sql

 

패키지가 생성되었습니다.

권한이 부여되었습니다.

뷰가 생성되었습니다.

패키지 본문이 생성되었습니다.

 

SQL> @C:\oracle\ora92\rdbms\admin\prvtpool.plb

 

뷰가 생성되었습니다.

패키지 본문이 생성되었습니다.

 

SQL> grant execute on dbms_shared_pool to scott;

 

권한이 부여되었습니다.

 

Object를 KEEP하는 방법은 다음과 같습니다.

 

Procedure,Function,Package : exec dbms_shared_pool.keep(‘pname’,’p’)
Trigger : exec dbms_shared_pool.keep(‘tr_emp’,’r’)
Sequence : exec dbms_shared_pool.keep(‘seq_empno,’q’)

SQL문은 아래와 같은 방법으로 KEEP 합니다.

 

예를들어 select empno, ename, sal from emp where deptno = ‘20’ 라는 SQL문장을 Library Cache안의 Shared Cursor 부분에 KEEP하기 위해서는 아래처럼 하면 됩니다…

 

SQL> conn scott/tiger

연결되었습니다.

 

SQL> select empno, ename, sal from emp where deptno = 20;

 

     EMPNO ENAME             SAL
---------- ---------- ----------
      7369 SMITH             800
      7566 JONES            2975
      7788 SCOTT            3000
      7876 ADAMS            1100
      7902 FORD             3000

 

SQL> conn / as sysdba

연결되었습니다.

 

SQL> select address, hash_value from v$sqlarea
  2  where sql_text = 'select empno, ename, sal from emp where deptno = 20';

 

ADDRESS  HASH_VALUE
-------- ----------
7856AC4C 1137127237   <- 원하는 SQL문장에 대한 주소와 해시 값

 

아래 명령으로  KEEP 합니다.

 

SQL> exec dbms_shared_pool.keep('7856AC4C, 1137127237','c');

 

PL/SQL 처리가 정상적으로 완료되었습니다.

 

Object의 KEEP 상태는 다음으로 체크 가능 합니다.

 

SQL> select distinct name, sharable_mem, loads
     from v$db_object_cache
     where name like '%emp%'
     and kept = 'YES';

 

NAME                                      SHARABLE_MEM      LOADS
------------ ----------------------------------------------
select empno, ename, sal from emp where deptno = 20   1469          1

 

또는 exec dbms_shared_pool.sizes(0)로 확인 가능 합니다. 이 sizes라는 procedure는 제한된 사이크 이상의 keep된 Object를 나타내 줍니다.

 

SQL> set serveroutput on size 2000

SQL> exec dbms_shared_pool.sizes(0)  -> buffer overflow가 나더라도 pin시킬(KEEP할) SQL문장을 찾을 수는 있습니다.

 

각 Object를 Shared Pool에 유지하던 것을 해제 할 때는 아래의 unkeep 프로시저를 이용 합니다.

 

SQL> exec dbms_shared_pool.unkeep('7856AC4C, 1137127237','c');

 

PL/SQL 처리가 정상적으로 완료되었습니다.

 

SQL> select distinct name, sharable_mem, loads
  2  from v$db_object_cache
  3  where name like '%emp%'
4  and kept = 'YES';

 

결과가 없겠죠…

 

☞  자주 사용되는 PL/SQL 블록을 캐싱한다.

- PL/SQL(프로시저,함수,패키지,트리거) 블록들은 너무 커서 실행시 마다 라이브러리 캐시영역
   에 로드되었다가 다시 제거되는 현상이 반복 --> 라이브러리 캐시영역의 단편화 현상 발생
- PL/SQL 블록 , SEQUENCE 등을 라이브러리 영역에 캐싱할 수 있도록 DBMS_SHARED_POOL
  패키지 제공.

SQL> select name,type,kept
         from v$db_object_cache
        where type in ('PACKAGE','PROCEDURE','TRIGGER','PACKAGEBODY');

NAME                      TYPE                 KEPT
------------------- ---------            ------
                                                             <= 캐싱된 PL/SQL 블록 정보가 없다
SQL>connect scott/tiger
SQL>create or replace procedure check_swan   <= 샘플 Procedure 생성
         (  v_emp_no in emp.empno%type )
          is
          begin
             delete from emp where empno = v_emp_no ;
        end check_swan ;
       /
  
SQL>execute DBMS_SHARED_POOL.KEEP('CHECK_SWAN')
                                <= 해당 프로시저를 공유 풀 영역에 상주.

SQL> select name,type,kept
         from v$db_object_cache
        where type in ('PACKAGE','PROCEDURE','TRIGGER','PACKAGEBODY');

NAME                      TYPE                 KEPT
------------------- -------------       ------
CHECK_SWAN          PROCEDURE          Y   <= 해당 프로지셔 캐싱

SQL>execute DBMS_SHARED_POOL.UNKEEP('CHECK_SWAN')


SQL> select name,type,kept
         from v$db_object_cache
        where type in ('PACKAGE','PROCEDURE','TRIGGER','PACKAGEBODY');

NAME                      TYPE                 KEPT
------------------- -------------       ------
CHECK_SWAN          PROCEDURE          N   <= 해당 프로지셔 캐싱 해제

 

 

 

 

 

☞  4-41 실습

 

 

아래의 쿼리를 이용하여 가장 빈번하게 사용되는 오브젝트를 찾을 수 있다.

select cache#, type, parameter, gets, getmisses, modifications mod 

from   v$rowcache 

where  gets > 0 

order by gets;





CACHE# TYPE        PARAMETER                GETS  GETMISSES    MOD


------ ----------- ------------------ ---------- ---------- ------


     7 SUBORDINATE dc_user_grants        1615488         75      0


     2 PARENT      dc_sequences          2119254     189754    100


    15 PARENT      dc_database_links     2268663          2      0


    10 PARENT      dc_usernames          7702353         46      0


     8 PARENT      dc_objects           11280602      12719    400


     7 PARENT      dc_users             81128420         78      0


    16 PARENT      dc_histogram_defs   182648396      51537      0


    11 PARENT      dc_object_ids       250841842       3939     75

 

row cache 튜닝은 매우 제한적이다. 최상의 솔루션은 V$ROWCACHE 의 결과를 기반으로 딕셔너리 접근을 줄이는 것이다. 예를 들어, 만일 시퀀스가 문제라면, 시퀀스를 캐슁하는 것을 고려할 수 있다. 여러 개의 테이블 조인을 포함하는 뷰 및 중첩된 뷰는 래치 경합을 증가시키게 된다. 일반적인 대안은 단순히 SHARED_POOL_SIZE를 증가하는 것이다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

기타>

 

 

 

LIBRARY CACHE LOCK WAIT EVENT가 나타날 때의 해결방법
====================================================

PURPOSE
-------
v$session_wait event 에 'library cache lock'이 발생하면서 session이
waiting 되는 경우가 있다. 오랫동안 이 현상이 지속될 경우 어떤 session이
이 library cache lock 을 갖고 있는지 확인해 볼 수 있다.

Explanation
-----------
v$session_wait view에 'library cache lock'이 나타날 수 있는 경우가
어떠한 것이 있는 지 알아보자.

예를 들어 다음과 같은 alter table 문장의 경우를 살펴보자.
 
 ALTER TABLE x MODIFY (col1 CHAR(200));

X 라는 Table의 row가 많다면 위의 문장으로 인해서 모든 row의 값이
200 bytes로 update되어야 하므로 굉장히 오랜 시간이 걸리게 된다.
이 작업 중에는 Table에 dml이 실행되어도 waiting되는 데, 이런 때에
'library cache lock' 이라고 나오게 된다.

또 package가 compile 되는 중에는 다른 user가 같은 package 내의
procedure나 function 등을 실행시켜도 waiting이 걸리면서 library cache
lock 이나 library cache pin event가 나타난다.

이 library cache lock 을 잡고 있는 session을 확인해 보자.

 

1. waiting session의 session address 확인

 library cache lock으로 waiting하고 있는 session의 sid를 찾아서
그 session address - v$session의 saddr column 을 확인한다.

2. 다음과 같은 sql로 해당 library cache lock을 잡고 있는 session을
확인할 수 있다.

 아래의 SQL 중에서 'saddr_from_v$session' 부분에 위의 1번에서 찾은
Waiting session의 saddr 값을 입력한다.
단, 아래의 sql은 반드시 sys 또는 internal user에서 실행해야 한다.

 

 SELECT SID,SERIAL#,USERNAME,TERMINAL,PROGRAM
 FROM V$SESSION
 WHERE SADDR in
  (SELECT KGLLKSES FROM X$KGLLK LOCK_A
   WHERE KGLLKREQ = 0
     AND EXISTS (SELECT LOCK_B.KGLLKHDL FROM X$KGLLK LOCK_B
                 WHERE KGLLKSES = 'saddr_from_v$session' /* BLOCKED SESSION */
                 AND LOCK_A.KGLLKHDL = LOCK_B.KGLLKHDL
                 AND KGLLKREQ > 0)
  );

3. 2번에서 확인한 blocking session에 의해 waiting하고 있는 session들도
확인할 수 있다. 2번에서 찾은 session의 saddr 값을 다음 sql에 대입하여
찾을 수 있다.

 

 

 SELECT SID,USERNAME,TERMINAL,PROGRAM
 FROM V$SESSION
 WHERE SADDR in
  (SELECT KGLLKSES FROM X$KGLLK LOCK_A
   WHERE KGLLKREQ > 0
     AND EXISTS (SELECT LOCK_B.KGLLKHDL FROM X$KGLLK LOCK_B
                 WHERE KGLLKSES = 'saddr_from_v$session' /* BLOCKING SESSION */
                 AND LOCK_A.KGLLKHDL = LOCK_B.KGLLKHDL
                 AND KGLLKREQ = 0)
  );

4. blocking session이 왜 오래 걸리는 것인지, v$session_wait 를 다시
확인하거나 실행하고 있는 sql 문장이나 object 등을 v$sql view 등을 확인
해 보아야 한다. 작업이라면 종료될 때까지 기다릴 수 있겠지만, 비정상적인
경우 또는 waiting session을 위해서는 다음과 같이 kill 할 수도 있다.

 

 

 alter system kill session 'SID, SERIAL#';

Common Cause for ORA-4031 in 10gR2, Excess "KGH: NO ACCESS" Memory Allocation [Video] [ID 801787.1]
		수정 날짜 16-AUG-2011     유형 PROBLEM     상태 PUBLISHED

In this Document
  Symptoms
  Cause
  Solution
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 - Release: 10.2 to 10.2
Information in this document applies to any platform.

Symptoms

Video - How to determine you are hitting this issue (02:44)

After several hours of database operation, ORA-4031 errors are reported.

An examination of the ORA-4031 trace file will show the Memory Allocation called "KGH: NO ACCESS" is consuming large amount of memory. For example the following shows over 500Mbytes  for this allocation.

Allocation Name             Size   

_________________________   __________

"free memory            "   163766600  

...

"KGH: NO ACCESS         "   560713888

Note that it is normal to periodically see "KGH: NO ACCESS" allocations up to about 64M.
This is memory that is in transition between SGA components when automatic memory management is resizing SGA components.  However, it is not normal to see persistent high allocations or a steady build up of this allocation type over time. The exception is when the database needs to make large changes i.e. when changing memory after a heavy load, or starting up using sub-optimal SGA settings, such as when an SPFILE is not being used.

The following query confirms that Memory Allocation "KGH: NO ACCESS" is large:

select * from v$sgastat where pool = 'shared pool' and (name in ('free memory', 'sql area', 'library cache', 'miscellaneous', 'row cache', 'KGH: NO ACCESS') );

The following query shows many GROW and SHRINK operations for "DEFAULT buffer cache" and "shared pool":

ALTER SESSION SET nls_date_format = 'DD/MM/YYYY HH:MI:SS';
SET PAGESIZE 900
SET LINESIZE 255
COL COMPONENT FORMAT A25
COL INITIAL_SIZE FORMAT A10
COL FINAL_SIZE FORMAT A10
SPOOL ASMM_RESIZE.TXT
select START_TIME, component, oper_type, oper_mode, initial_size/1024/1024 "INITIAL", FINAL_SIZE/1024/1024 "FINAL", END_TIME
from v$sga_resize_ops
where component in ('DEFAULT buffer cache', 'shared pool') and status = 'COMPLETE'
order by start_time, component;
SPOOL END

Cause

Too frequent resizes of Shared Pool and Buffer Cache, leading to excess "KGH: NO ACCESS" memory allocation, that consumes SGA memory.

Several bugs have been logged for this problem, for different versions within 10gR2;

• Fixed 10.2.0.2
  Unpublished Bug 4507532: SGA_TARGET DOESN'T WORK AS EXPECTED
  Bug 5045507 ASMM - FREQUENT RESIZING OF SHARED POOL & BUFFER CACHE
• Fixed 10.2.0.4
  Unpublished Bug 6528336: APPSST 10G GSI: LARGE NUMBER OF SESSIONS WAITING ON CURSOR: PIN S WAIT ON X
• Fixed 10.2.0.5
  Unpublished Bug 7189722: APPSST GSI 10G: VERY FREQUENT GROW/SHRINK SGA RESIZE OPERATION HAPPENING

If you are seeing this in version: 11.1.0.6 to 11.2.0.1, please see note:
Note 1127833.1 ORA-04031 in 11g & 11gR2, Excess "KGH: NO ACCESS" Memory Allocation

Solution

 In summary;

1. Disable ASMM

OR

2. Set the minimum values for the Shared Pool and the Database Buffer Cache

OR

3. Increase the time between resize operations

OR

4. Apply the fix, by either upgrading or applying a one-off patch, depending on your version.

To fix the problem being encountered, where excessive ASMM resize operations leads to the "KGH: NO ACCESS" memory allocation consuming the memory available to the SGA, the above solutions are available, as per MetaLink notes;
Note 451960.1 How To Prevent The Growth Of The Component 'KGH: NO ACCESS' In The Shared Pool When ASMM Is Enabled
Note 742599.1 FREQUENT RESIZE OF SGA

Disabling ASMM will mean memory is no longer swapped between the pools, but it does require the SGA parameters to be set manually.

Setting minimum values for the Shared Pool and Buffer cache when ASMM is enabled means ASMM is still in operation, but any operations that would try to change the SGA component sizes below the minimum values will not occur, leading to less memory needing to pass through the "KGH: NO ACCESS" memory allocation. This is the only operation that does not need a database shutdown/startup.

Increase the time between the resize operations will mean that the default of 30 seconds is increased to a much larger time interval.

Finally, applying the patch or upgrading will fix the code in accordance to Oracle Development recommendations.

Solution 1: Disable ASMM and revert to setting the SGA Manually

1. Determine reasonable values for SGA Parameters DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE and STREAMS_POOL_SIZE (as apprioriate).
   For further assistance, please review MetaLink note:
   Note 1008866.6 How to determine SGA Size (7.x, 8.0.x, 8i, 9i, 10g)
2. Disable ASMM:
   SQL> alter system set SGA_TARGET=0 scope=spfile;
3. Set the SGA pool sizes manually, using the values you determined from Step 1 (above):
   For example:
   SQL> alter system set SHARED_POOL_SIZE=1G scope=spfile.
   NOTE: Not all the parameters may need to be set, and will default to 0.
4. Shutdown and startup the database, so that ASMM is turned off, and the new manual SGA settings take affect.
   

Solution 2: Leave ASMM enabled, but set minimum values for the Shared Pool and Buffer Cache

1. During a typical, busy period on the database, run the following query:
   SET PAGESIZE 100
   COL COMPONENT FORMAT A25
   COL FINAL_SIZE FORMAT A15
   select component, AVG(FINAL_SIZE) "AVG FINAL", MEDIAN(FINAL_SIZE) "MEDIAN FINAL", MAX(FINAL_SIZE) "MAX FINAL"
   from v$sga_resize_ops
   group by component;
2. For the row "DEFAULT buffer cache", determine which value is greater, "AVG FINAL" or "MEDIAN FINAL".
   Record this value as the Minimum Buffer Cache n.
3. For the row "shared pool", determine which value is greater, "AVG FINAL" or "MEDIAN FINAL".
   Record this value as the Minimum Shared Pool m.
4. Add together the values for the Minimum Buffer Cache & Minimum Shared Pool, and compare this to your current SGA_TARGET or SGA_MAX_SIZE.
5. If the total is greater than SGA_TARGET or SGA_MAX_SIZE, then they will also need to be increased. Determine how big SGA_TARGET or SGA_MAX_SIZE can be, and then implement the increase, for example:
   SQL> ALTER SYSTEM SET SGA_TARGET=nnn SCOPE=BOTH;
6. Set parameter DB_CACHE_SIZE to the value of the Minimum Buffer Cache (as per Step 2 above).
   SQL> ALTER SYSTEM SET DB_CACHE_SIZE=n SCOPE=SPFILE;
7. Set parameter SHARED_POOL_SIZE to the value of the Minimum Shared Pool (as per Step 3 above).
   SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=m SCOPE=SPFILE;
8. Re-start the database.
   
9. Alternately, you can try to perform the memory changes without re-starting the database.
   However, you need to determine what the dynamic settings are first, by running the following query:
   SQL> select component, current_size from v$sga_dynamic_components where component like '% pool' or component = 'DEFAULT buffer cache';
10. If both the "shared pool" and the "DEFAULT buffer cache" are less than the minimum values determined in Steps 2  & 3 above, then you can try using SCOPE=BOTH, when setting the DB_CACHE_SIZE and SHARED_POOL_SIZE.
    

Solution 3: Increase the time between resize operations

1. Review the Solutions from Note 742599.1, in particular, the solution involving parameter "_memory_broker_stat_interval".
2. For your database, determine a reasonable period of time for the delay between resize operations, given the default is 30 seconds.
   
3. Set parameter "_memory_broker_stat_interval" to the time period n you determined in Step 2 (above):
   SQL> ALTER SYSTEM SET "_memory_broker_stat_interval"=n SCOPE=SPFILE;
4. Shutdown and startup the database, so that the underscore parameter takes affect.
   

Solution 4: Apply the fix

10.2.0.1

If you are using v10.2.0.1, upgrade to a minimum of v10.2.0.3 (or, see below).

10.2.0.2

If you are using v10.2.0.2, no bugs have been logged for this version, so it is recommended that you upgrade (see below).

10.2.0.3

1. Download and review the readme and pre-requisites for Patch 6528336
   As of April 2009, the platforms are; Linux x86, IBM AIX 64-bit, HP-UX Itanium.
   
2. If the patch does not exist for your platform, please log a Service Request, requesting a Backport of Bug 6528336 to your platform.
   

10.2.0.4

1. Download and review the readme and pre-requisites for Patch 7189722
   As of April 2009, the platforms are; Linux x86, Linux x86-64, IBM AIX 64-bit, HP-UX Itanium, Sun Solaris SPARC 64-bit.
   
2. If the patch does not exist for your platform, please log a Service Request, requesting a Backport of Bug 7189722 to your platform.

OR Oracle recommends that you upgrade to v10.2.0.5, when it is available for your platform.

References

BUG:5045507 - ASMM - FREQUENT RESIZING OF SHARED POOL & BUFFER CACHE
NOTE:1008866.6 - How to determine SGA Size (7.x, 8.x, 9.x, 10g)
NOTE:1127833.1 - ORA-04031 in 11g & 11gR2, Excess "KGH: NO ACCESS" Memory Allocation
NOTE:451960.1 - How To Prevent The Growth Of The Component 'KGH: NO ACCESS' In The Shared Pool When ASMM Is Enabled
NOTE:742599.1 - High 'cursor: pin S wait on X' and/or 'library cache lock' Waits Generated by Frequent Shared Pool/Buffer Cache Resize Activity

첨부 파일 How to determine you are hitting this issue (2,687.61 KB)

관련 자료 제품 Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition 키워드 SHARED POOL; SIZING; V$SGASTAT; V$SGA_DYNAMIC_COMPONENTS; V$SGA_RESIZE_OPS; VIDEO; DYNAMIC ADV DIAGNOSTIC TOOLS; DYNAMIC ADV TRAINING 오류 ORA-4031; 4031 ERROR