database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Tutorials 9000 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 9000
Oracle Library Cache and Dictionary Cache
작성자
정재익(advance)
작성일
2001-12-23 03:08
조회수
5,328

Oracle Library Cache and Dictionary Cache

 

Library Cache

 

■ The V$LIBRARYCACHE Table

· 가장 최근의 인스탄스 startup이후 모든 library cache activity를 나타냄

· Library cache 행동을 감시

· 사용자 SYS 와 SELECT ANY TABLE 시스템 권한을 가진 사용자, 즉 SYSTEM과 같은 사용자만이 이용

    NAMESPACE column : SQL 문장과 PL/SQL 블록들을 위한 library cache activity
         ('SQL AREA', 'TABLE/PROCEDURE', 'BODY', 'TRIGGER') 
    PINS: library cache 내의 항목이 실행된 수
    RELOADS : 실행단계에서의 library cache miss의 수 

■ Querying the V$LIBRARYCACHE Table 

   SELECT SUM(pins) "Executions",
       SUM(reloads) "Cache Misses while Executing"
    FROM v$librarycache;


    [ 질의의 결과 ] 

             Executions   Cache Misses while Executing
               ----------  -------------------------
                 320871                           549

1. PINS column의 합은 SQL 문장, PL/SQL blocks, object 정의가 총 320,871번 실행하기 위해 access 되었음

2. RELOADS의 합은 실행횟수 중 549번의 실행이 library cache의 대 기 상태를 발생

3. 총 PINS에서 총 RELOADS의 비율 : 0.17%

 

총 RELOADS는 0에 가까워야 하고 PINS에서 RELOADS의 비율이 1% 이상이라면 library cache miss들을 줄여야 함

 

 

Dictionary Cache

 

■ The V$ROWCACHE View

 

· V$ROWCACHE TABLE 질의 : 캐쉬 기능을 확인하기 위해

PARAMETER : Data dictionary item, 'dc_'로 시작

ex) file description을 위한 통계 : dc_files

GETS : Data dictionary의 각 부분에 대한 요구 횟수

GETMISSES : 캐쉬 miss를 발생시키는 데이타 요구의 수

COUNT : 사용가능한 캐쉬 entry의 총수

USAGE : 그 중에서 데이타를 저장하고 있는 캐쉬 entry의 수

GETMISSES 대 GETS의 비율 10~15%를 초과할 경우 data dictionary cache가 사용할수 있는 메모리를 증가

→ SHARED_POOL_SIZE값 증가시킴.

 

 

멀티쓰레드서버에서 shared pool 튜닝

 

▶ Sard pool의 크기 증가 → SHARED_POOL_SIZE 증가시킴

 

 

Buffer Cache

♣ V$SYSSTAT 
▶ 버퍼 캐쉬 튜닝을 위해 사용 
   db block gets, consistent gets : 합은 데이타를 요구하는 총 횟수 
   physical reads : 디스크상의 datafile에 access한 data 결과로써 request의 총 횟수 
▶ 적중률(hit ration) : 데이타가 디스크에서 읽혀지지 않고 메모리에서 읽혀지는 비율 
       1 - ( physical reads / (db block gets + consistent gets))  


1.  Reducing Buffer Cache Misses 
  - 적중률이 60%~70%보다 작다면 성능향상을 위해 캐쉬내 버퍼의 수를 증가 
  - 버퍼 캐쉬를 더 많이 만들기 위해서 초기화 파라메터 DB_BLOCK_BUFFERS를증가  

-  X$KCBRBH 
- 초기화 파라메터 DB_BLOCK_LRU_EXTENDED_STATISTICS에 의해 조절 
[ 예제 ] 
     캐쉬에 20개의 버퍼를 추가했을 때 얼마나 많이 캐쉬 적중이 일어날 것인지 를 결정 
      SELECT SUM(count) ach 
      FROM sys.x$kcbrbh 
      WHERE indx <20; 
 적중률 = 1 - (physical reads - ACH/(db block gets + consistent gets))  

2.  Removing Unnecessary Buffers
♣ X$KCBCBH  
- 더 작은 캐쉬의 성능을 판단하는 통계치를 포함 
-  X$KCBCBH 테이블은 X$KCBRBH 테이블의 구조와 비슷 
-  DB_BLOCK_LRU_STATISTIC = TRUE로 설정함으로써 통계치를 collect. 
 
 [ 예제 ] 
  현재 버퍼가 100 버퍼라면 990버퍼로 줄었을 때의 cache miss는 얼마일까? 
      SELECT SUM(count) acm
      FROM sys.x$kcbcbh
      WHERE indx >= 90; 
  적중률 = 1- (physical reads + ACM / (db block gets + consistent gets)) 

 

Rollback Segment

 

·system undo header : 이 statistics의 값은 SYSTEM rollback segment의 header block를 포함하는 buffer들을 기다리는 수이다.

·system undo block : 이 statistics의 값은 SYSTEM rollback segment의 header block 이외의 다른 block들을 포함하는 buffer들을 기다리는 수이다.

·undo header : 이 statistics의 값은 SYSTEM rollback segment의 header block 이외의 다른 rollback segment의 header block들을 포함하는 buffer들을 기다리는 수이다.

·undo block : 이 statistics의 값은 SYSTEM rollback segment이외의 다른 rollback segments 의 header block과는 다른 blocks들을 포함하는 buffer들을 기다리는 수이다.

 

▶ ·SELECT class, count 
     FROM v$waitstat 
     WHERE class IN ('system undo headr', 'system undo block', 'undo header', 'undo block'); 


▶  결과값은 
CLASS COUNT  
------------------------------------ ------------------ 
system undo header 2089  
system undo block 633  
undo header 1235  
undo block 942  

▶  동일한 시점에서 데이터를 요구하는 총 수를 비교하라.
▶ ·SELECT SUM(value) 
     FROM v$sysstat 
     WHERE name IN ('db block gets', ' consistent gets'); 

▶  결과값은 
SUM(VALUE) 
---------------------- 
929530 

▶ 각 계층들을 위해 기다리는 값들이 요구하는 총수의 1% 보다 더 크다면 contention의 감소를 위해 더 많은 rollback segment의 생성을 고려해야 한다.

 

Redo log buffer

 

1. Space in the Redo Log Buffer

▶ Redo log space request에 대한 statistic은 user process가 redo log buffer에 있는 공간이 할당되기를 기다리는 시간이다.

·SELECT name, value
              FROM V$SYSSTAT 
              WHERE name = 'redo log space requests'; 

▶ 이 값이 일관성있게 증가하면 process 는 버퍼의 공간을 위해 기다려야만 한다. 이 경우 redo log buffer의 크기는 증가시켜라.

▶ Redo log space requests의 값이 0에 가까울 때 까지 5%씩 redo log buffer의 크기가 증가시키도록 하라.

 

2. Redo Log Buffer Latches

 

1) The Redo Allocation Latch

▶ redo log buffer에서 redo entry를 위한 공간을 할당하는 것을 제어한다.

▶ 버퍼에 공간을 할당할 때는, 오라클 유저 프로세스가 반드시 redo allocation latch를 가지고 있어야만 한다.

▶ 만약 단 하나의 redo allocation latch가 있다면 한번에 단 하나의 유저 프로세스만인 버퍼에 공간을 할당하는 것이 가능하다.

▶ redo allocation latch에 복사한후 유저 프로세서는 latch를 해제한다.

▶ LOG_SMALL_ENTRY_MAX_SIZE

 

2) Redo Copy Latches

▶ Redo entry가 너무 커서 redo allocation latch에 복사할 수 없다면, 유저 프로세서는 버퍼에 entry를 복사하기 전에 redo copy latch를 갖고 있어야만 한다.

▶ redo copy latch를 잡고 있는 동안, 유저 프로세서는 버퍼에 할당된 공간 안에 redo entry를 복사한 후, redo copy latch를 해제한다.

▶ LOG_SIMULTANEOUS_COPIES

 

3) Redo Log Activity

▶ V$LATCH

·GETS : 이 칼럼은 latch에 대한 willing-to-wait 요구가 성공된 수

·MISSES : 이 칼럼은 초기 willing-to-wait가 성공된 시간의 수

·SLEEPS : 이 칼럼은 초기 willing-to-wait request이후에 한 프로세스가 latch를 요구하고, 기다린 시간의 수

- latch에 대한 요구가 성공될 때 GETS값이 하나 증가한다.

- latch에 대한 초기 요구가 waiting의 결과를 가질 때 MISSES값이 하나 증가한다.

- 프로세스가 latch를 두 번씩(initial request후에 한번, 두 번째 request후에 다시 한 번) 기다렸으므로 SLEEPS값은 둘 증가한다.

·MMEDIATE GETS : 각 latch에 대한 immediate request가 성공한 수

·IMMEDIATE MISSES : 각 latch에 대한 immediate request가 성공하지 못한 수

·SELECT ln.name, gets, misses, sleeps, immediate_gets, immediate_misses 
               FROM v$latch l, v$latchname ln 
               WHERE ln.name IN ('redo allocation', 'redo copy') AND ln.latch# = l.latch#; 

▶  결과
NAME GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES 
------------------  --------------------------  --------------------------  --------------------------  --------------------------  
redo allo....  252867  63  0  0  
redo copy  0  0  22830  0  

·If the ratio of MISSES to GETS exceeds 1% => (MISSES/GET) * 100 
·if the ratio of IMMEDIATE_MISSES to the sum of IMMEDIATE_GETS and IMMEDIATE_MISSES exceeds 1% 
=> (IMMEDIATE_MISSES/(IMMEDIATE_GETS + IMMEDIATE_MISSES)) * 100 

 

3. Reducing Latch Contetion

 

● 2개 이상의 오라클 프로세스가 동시에 동일한 latch를 갖고자 할 때 대부분의 경우 latch contention이 일어난다.

● latch contention은 하나의 프로세스가 한번씩 동작하는 single-CPU computer인 경우는 드물게 일어난다.

 

1) Reducing Contention for the Redo Allocation Latch

▶ LOG_SMALL_ENTRY_MAX_SIZE의 값을 감소시킴으로서 redo allocation latch에 복사된 redo entry 의 크기와 수를 감소할 수 있다.

 

2) Reducing Contention for Redo Copy Latches

▶ LOG_SIMULTANEOUS_COPIES의 값을 증가

 

Multi-threaded server

 

1. Reducing Contention for Dispatcher Processes

 

1) Identifying Contention for Dispatcher Processes

 

Busy Rates for Dispatcher Processes

▶ V$DISPATCHER

·SELECT network "Protocol", SUM(busy) / ( SUM(busy) + SUM(idle) ) "Total Busy Rate" 
               FROM v$dispatcher 
              GROUP BY network; 

▶ 만약 특별한 프로토콜의 dispathcher process가 시간당 50%이상씩 바쁘게 되면, dispatcher process를 증가시킴으로서 성능향상에 좋을 수 있다.

 

Wait Times for Dispatcher Process Response Queues

▶ V$QUEUE

·SELECT network "Protocol", 
              DECODE( SUM(totalq), 0 ,'NO RESPONSES',
              SUM(wait)/SUM(totalq) || 'hundredths of seconds ')
              "Average Wait Time per Response"
              FROM v$queue q, v$dispatcher d 
              WHERE q.type = 'DISPATCHER' AND q.paddr = d.paddr GROUP BY network ; 

▶ 특별한 네트워크 프로토콜을 위한 평균 wait time이 application이 동작중일 때 고정적으로 계속 증가된다면, dispatcher process를 추가시킴으로서 성능을 향상시킬 수 있울 것이다.

 

2) Adding Dispatcher Processes

▶ ALTER SYSTEM 명령 : MTS_DISPATCHER parameter를 를 추가

▶ MTS_MAX_DISPATCHERS

 

2. Reducing Contention for Shared Server Porcesses

 

1) Identifying Contention for Shared Server Processes

▶ V$QUEUE

·SELECT DECODE (totalq, 0, 'NO Requests', wait/totalq || 'hundredths of seconds') 
              "Average Wait Time Per Requests" 
              FROM v$queue
              WHERE type = 'COMMON' ; 

▶ 얼마나 많은 shared server process가 동시에 동작하는지

·SELECT COUNT(*) "Shared Server Processes" 
              FROM v$shared_servers 
              WHERE status != 'QUIT'; 

2) Adding Shared Server Processes

▶ MTS_MAX_SERVERS

▶ 오라클이 자동적으로 shared server process를 증가하거나 명시적으로 아래 방법중 하나를 통해서 shared process를 증가시킬수 있다.

·ALTER SYSTEM 명령의 MTS_SERVERS parameter

[Top]
No.
제목
작성자
작성일
조회
9003OCP 문제 - ADMIN 파트 (2)
정재익
2001-12-23
12240
9002OCP 문제 - Admin 파트 (3)
정재익
2001-12-23
6388
9001OCP 문제 - ADMIN 파트 (1)
정재익
2001-12-23
13736
9000Oracle Library Cache and Dictionary Cache
정재익
2001-12-23
5328
8913Oracle Performance Tuning SQL Scripts
정재익
2001-12-14
6604
8909Oracle System Documentation
정재익
2001-12-14
5397
8875오라클 퍼포먼스 향상방법
정재익
2001-12-13
4737
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2022 DSN, All rights reserved.
작업시간: 0.147초, 이곳 서비스는
	PostgreSQL v14.2로 자료를 관리합니다