h1.라이브러리 캐시 구조

라이브러리 캐시 : shared pool내에 위치하고 있으며 SQL공유커서 , DB오브젝트 정보 , 프로시저 , 함수 , 패키지 , 트리거 등 pl/sql 프로그램을 담는 pl/sql area도 저장한다.

그리고 이곳에 저장되는 정보의 단위를 라이브러리 캐쉬 오브젝트(LCO)라고 부르며 데이터 딕셔너리 캐시와 함께 shared pool에 할당받은 메모리공간을 사용한다.

h3.라이브러리 캐시 특징

   1.SQL문 수행과 관련된 모든 정보를 저장

   2.LRU 알고리즘을 사용하여 관리 (Data Buffer Cache와 동일)

   3.Shared pool latch : shared pool에서 특정 Object정보 나 SQL커서를 위한 free chunk 할당 받을 때 필요

                                     9i 이전까지는 1개로 몯느걸 처리 했지만 9i 이후부터는 Shared pool을 Sub Pool로 관리가 가능해 지면서 7개 까지 사용 할수있게 됨.

                                     (단, CPU가 2개 이상이어야 하며 2개이면 3개 4개이면 5개 사용 할수 있다.

h3.라이브러리 캐시 오브젝트(LCO) :라이브러리 캐시에 저장되는 정보의 단위

h5.정보의 분류

 실행가능 LCO - Package , Trigger, Procedure , Function 
 오브젝트 LCO - 테이블 , 인덱스 , 클러스터와 같은 데이터베이스 오브젝트(데이터 딕셔너리 캐시에도 있지만 LCO에도 저장하는 이유는 의존성을 관리하기 위함)

OR

 Stored Object - 생성 후 Drop 하기 전가지 데이터 베이스에 영구적으로 보관되는 오브젝트(테이블,인덱스 패키지 등등) 
 Transient Object - 인스턴스가 떠있는 동안에마 존재하는 일시적인 오브젝트(커서와 Anonymous PL/SQL)

v$librarycache

gets : 시스템이 이 네임스페이스의 객체에 대한 핸들을 요청한 회수
pins : 캐시의 객체가 실행된 횟수 . 값이 높을수록 이러한 명령무이 메모리에서 실행되었음을 의미.
pinhits : 기존 pin을 재사용할 수 있는 요청 수.
gethits : 캐시에 존재하는 객체에 대한 요청 수.
reloads : 객체 중 일부가 캐시에서 비워져 라이브러리 캐시에 저장된 객체가 메모리에 재로드된 회수. 
invalidations : 객체가 무효화된 회수. 객체는 더 이상 실행하기에 안전하지 않을 때 오라클 데이터베이스에 의해 자동으로 무효화됩니다

h3.라이브러리 캐시 구조

Library Cache 메모리는 Library Cache Manager(KGL, Kernel Generic Library Cache)에 의해 관리되는데, KGL은 KGH를 이용해서 필요한 메모리 청크를 할당 받는다.

 - Library Cache 메모리는 [해시 테이블 -> 버킷 -> 체인 -> 핸들 -> 오브젝트]의 구조로 되어 있다. 
 - 오라클은 객체 이름(가령 SQL 텍스트)에 해시함수를 적용해 생성된 해시값을 이용해 적절한 해시 버킷(Hash Bucket)을 할당하며, 
   같은 해시값을 지니는 객체들은 체인(리스트)으로 관리된다. 
 - 하나의 Library Cache 핸들(이하 핸들)은 하나의 Library Cache Object(이하 LCO)를 관리한다. 핸들은 실제 LCO에 대한 메타정보 
    및 포인터 역할을 하며 LCO가 실제 정보를 담고 있다. 
 - LCO가 포함하는 정보 중 중요한 것들은 다음과 같다. 
   - Dependency Table, Child Table, Data Blocks

h3.라이브러리 캐시 작동과정