라이브러리 캐시는 Shared Pool 내에 위치하며，SQL 공유 커서 및 데이터베이스 오브젝트(테이블,인덱스 등)에 대한 정보를 관리
그리고 여기에 저장되는 정보의 단위를 라이브러리 캐시 오브젝트(LCO)

라이브러리 캐시에 스키마 오브젝트 정보를 캐싱하는 것은
LCO간 의존성 (dependency)을 관리하려는 데에 목적이 있다.
LCO 각각에는 자신을 참조하는 다른 실행가능 LCO(커서,함수,프로시저,패키지 등) 목록을 갖는다.

select namespace, gets, pins, reloads , invalidations
from v$librarycache ;
NAMESPACE             GETS       PINS    RELOADS INVALIDATIONS
--------------- ---------- ---------- ---------- -------------
SQL AREA              3062      23111        298             0
TABLE/PROCEDURE       4511       9331        193             0
BODY                   234       1623         13             0
TRIGGER                 22        129          3             0
INDEX                   57         57          0             0
CLUSTER                110        284          2             0
OBJECT                   0          0          0             0
PIPE                     0          0          0             0
JAVA SOURCE              0          0          0             0
JAVA RESOURCE            0          0          0             0
JAVA DATA                0          0          0             0

Shared Pool도 DB 버퍼 캐시처럼 LRU 알고리즘에 의해 관리
Shared Pool에서 특정 오브젝트 정보 또는 SQL 커서를 위한 만ee Chunk를 할당 받
으려 할 때 필요한 래치가 shared pool 래치다.

예전보다 늘긴 했지만 사용할 수 있는 래치 개수가 7개뿐 그 이상의 동시 사용자가 순간적으로
과도한 하드 파싱 부하를 일으킨다면 shared pool 래치에 대한 경합현상이 나타날수 있는것이다.

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 IMMEDIATE_MISSES 
--------- --------- --------- --------- -------------- ---------------- 
        1  62927831      9289         8              0                0
        2  66431192      9543         4              0                0
        3       372         0         0              0                0
        4       372         0         0              0                0
        5       372         0         0              0                0
        6       372         0         0              0                0
        7       372         0         0              0                0

7 rows selected.

소프트/하드 파싱부하시 - shared pool 래치, libraη cache 래치 경합
SQL 수행 도중 DDL 시 - libraη cache lock과 library cache pin 대기 이벤트

라이브러리 캐시 최적화를 위한 데이터베이스 관리자 측면에서의 튜닝 기법들이 몇 가지 있지만，
그보다 중요하고 효과가 큰 것은 개발 측면에서의 노력이며 아래 3가지로 요약할 수있다

커서를 공유할 수 있는 형태로 SQL을 작성 한다.
(특히 바인드 변수를 사용해 같은 형태의 SQL에 대한 반복적인 하드파싱이
세션 커서 캐싱 기능 을 이용해 라이브러리 캐시에서 SQL 찾는 비용을 줄인다 .
애플리케이션 커서 캐싱 을 이용해 Parse Call 발생량을 줄인다.

h3.LATCH 란? - 오라클 AWR을 이용한 고성능 데이터베이스 튜닝

h5.렛치의 정의
Latch : 메모리 및 일부 핵심코드 사용의 동시성을 관리하기 위한 락

h5.렛치의 특성
1. 렛치는 엔큐 락에 비해 구조 및 획득 메커니즘이 간단
2. 매우 짧은시간 안에 획득 및 획득 해제가 수행
3. 오라클은 SGA를 구성하는 각 자원을 관리하는 한개 이상의 렛치있다.

11g기준
SQL> select count(*) from v$latch;
535 개의 행이 선택되었습니다.

4. 렛치는 베타적모드와 공유모드로 적용 가능

• 렛치로 관리되는 자원에 변경작업을 수행하려면 배타적모드로 렛치 획득
• 배타적 모드가 적용된 경우 어떤 모드의 렛치도 허용하지 않음
• 다른 프로세스는 해당 자원에 접근할수 없고 렛치를 획득한 프로세스는
  단독으로 해당 자원을 사용하는 것이 보장됨
• 렛치는 대부분 배타적 모드로 요청

h5.레치의 동작예

1. 프로세스1이 라이브러리캐시를 사용하기 위해 배타적모드로 library cache 렛치획득을 요청
2. 타 프로세스가 해당 렛치를 사용하고 있지 않으므로 렛치를 획득하며 프로세스1은 라이브러리캐시 사용
3. 프로세스2가 라이브러리캐시를 사용하기 위해 배타적모드로 library cache 렛치획득을 요청
4. 프로세스1이 해당 렛치를 사용 하기때문에 획득 가능할때까지 CPU에서 스핀을 수행
5. 프로세스3이 라이브러리캐시를 사용하기 위해 배타적모드로 library cache 렛치획득을 요청
6. 프로세스1이 해당 렛치를 사용 하기때문에 획득 가능할때까지 CPU에서 스핀을 수행

스핀이란?

프로세스가 요정한 렛치를 획득할 수 없을 경우 획득가능할 때까지 CPU 자원을 사용하며 반복요청하는 행위.
히든파라메터에 의해 반복수행되며 기본 값은 2000임.

7. 프로세스2가 _SPIN_COUNT파라미터에 지정된 수만큼 스핀을 수행하여 슬립 상태
8. 프로세스1이 라이브러리캐시를 사용하면서 library cache렛치획득을 해제
9. 프로세스3이 library cache렛치를 획득
(스핀수행 중 먼저 획득할수 있는 프로세스가 요청한 순서에 상관없이 획득)

슬립이란?

프로세스가 지정한스핀횟수만큼 렛치를 요청했음에도 불구하고 획득에 실패한 경우 CPU자원 사용을 중지하고 잠시 대기
최초 슬립 상태를 유지하는 시간은 0.01초이며 다시_SPIN_COUNT에서 설정한 횟수만큼 스핀을 수행 렛치획득을 요청

10.프로세스4가 라이브러리캐시 사용을 위해 배타적모드로 library cache렛치획득을 요청
11.프로세스3이 해당렛치를 획득하고 있으므로 획득 가능할때까지 CPU에서 스핀을 수행
12.슬립 상태에서 깨어난 프로세스2도 해당렛치를 획득할 수 없으므로 스핀을 재수행

렛치 경합이 발생하는 경우，시스탱의 CPU사용량이 급격히 올라감