.  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 발생량을 줄임