메뉴 건너뛰기

bysql.net

3._라이브러리_캐시_구조

2012.04.06 02:40

dasini 조회 수:5229

 

 

 .  SQL 공유커서 및 데이터베이스 오브젝트에 대한 정보를 관리
    -> LCO 간의 의존성을 관리
 .  실행가능 LCO    :    SQL 커서, PL/SQL 오브젝트 처럼 실행가능한 오브젝트
.   오브젝트 LCO    :    테이블, 인덱스, 클러스터와 같은 오브젝트


select namespace, gets, pins, reloads, invalidations from v$librarycache;

 

NAMESPACE GETS PINS RELOADS INVALIDATIONS
SQL AREA 3678513629 3521744657 8759434 1830568
TABLE/PROCEDURE 428295313 608934534 681427 0
BODY 2719124660 3160973185 31047 0
TRIGGER 1813449 2288323 443 0
INDEX 11449732 187584212 52203 0
CLUSTER 158944 300240 672 0
OBJECT 0 0 0 0
PIPE 0 0 0 0
JAVA SOURCE 7 7 0 0
JAVA RESOURCE 7 7 1 0
JAVA DATA 0 0 0

0

 

 

 1. 생성후 DROP 하기 전까지 데이터베이스에 영구적으로 보관되는 오브젝트
                 : 테이블, 인덱스, 클러스터, 뷰, 트리거, 패키지, 사용자 정의함수/프로시저,   생성될 때부터 이름을 갖음
 2. 인스턴스가 떠있는 동안에만 존재하는 일시적인 오브젝트
                 : 커서와 Anonymous PL/SQL

 

. LUR 알고리즘에 의해 관리됨
   -> 재사용 빈도가 낮은 SQL 은 캐시에서 밀어냄
 . Shared pool 래치    :    Shared Pool에서 특정 오브젝트 정보 또는 SQL 커서를 위한 Free Chunk를 할당 받으려 할때 필요한 래치

 

 
SELECT child#, gets, misses, sleeps, immediate_gets, immediate_misses
from v$latch_children
where name = 'shared pool'
order by child#

CHILD# GETS MISSES SLEEPS IMMEDIATE_GETS
1 3152049157 60619994 1479690 0
2 2962901122 49835056 1150331 0
3 612 0 0 0
4 612 0 0 0
5 612 0 0 0
6 612 0 0 0
7 612 0 0 0

 

 

--> 7개의 래치중에 2개만 사용됨

      만약 동시 사용자가 순간적으로 과도한 하드 파싱 부하를 일으킨니다면 shared pool 래치에 의한 경합 현상이 나타날 수 있음

 

 

  . DB 버퍼 캐시처럼 해시 구조로 관리됨

    해시버킷에 LCO 핸들이 체인으로 연결되어 있고, 핸들을 통해 LCO 힙을 찾아가는 구조

    DB 버퍼 캐시와 마찬가지로 해시 함수를 통해 리턴된 해시값을 가지고 버킷을 할당

 

 

 

 

 

 . 오브젝트 LCO인 EMP 테이블 정보와 실행가능 LCO에 해당하는 SQL 커서가 라이브러리 캐시에 함께 적재

 . 커서는 Parent 커서 밑에 Child 커서가 연결되는 구조를 갖음

 

.라이브래리 캐시 체인을 탐색하고 변경하려면 library cache래치를 획득해야 함

         -> 경합이 발생하게 되면 latch : library cache 대기 이벤트가 발생

        -> 갯수가 몇개에 불과하므로 하드파싱과 소프트 파싱이 많이 발생해도 래치에 대한 경합이 증가

 

. LCO를 보호하려고 오라클은 라이브러리 캐시 Lock과 라이브러리 캐시 Pin을 사용

         1. LCO에 접근 할 때는 먼저 핸들에 대한 Lock을 획득 해야함

         2. 실제 내용이 담긴 힙에서 정보를 읽거나 변경할 때는 Pin을 걸어 두어야 함

 

. shared pool 래치와 library cache 래치 경합은 소프트/ 하드 파싱을 동시에 심하게 일으킬때 발생

 . library cache lock 과 library cache pin 대기 이벤트는 주로 SQL 수행도중 DDL을 날릴때 발생

 

. 라이브러리 캐시 최적화를 위한 데이터베이스 관리자 측면에서의 튜닝 기법

        1. 커서를 공유할 수 있는 형태로 SQL을 작성 -> 바인드 변수 사용

        2. 세션 커서 캐싱 기능을 이용해 라이브러리 캐시에서 SQL을 찾는 비용을 줄임

        3. 애플리케이션 커서 캐싱을 이용해 Parse Call 발생량을 줄임