Library Cache

1. System Global Area 구성

1. SGA(System Global Area)
   1. 디스크에서 읽어온 데이터를 저장하는 메모리 영역
   2. 저장된 데이터를 읽거나 변경 작업에서 사용되는 공용 메모리 영역
   3. SGA사용 목적 : 메모리 사용을 최소화하면서 처리성능 최대화
      
      
      
2. Shared Pool - SQL, PL/SQL 수행에 필요한 정보 저장
   1. 목적 : 한번 처리된 SQL의 실행 정보를 공유함으로써 자원의 사용을 최소화하고 SQL 수행속도 증가
   2. Variable 영역 : Shared Pool + Java Pool + Large Pool + Streams Pool
   3. Permanent Area(시스템 영역, 고정영역)ㅍㄷㄱ냐ㅐㅜ
      • SGA 관리 메커니즘 및 오라클 파라미터 정보 저장
      • 자동 할당, 사용자 지정 No
      • SGA구성 요소 중 Fixed Size에 해당
   4. Library Cache
      • PL/SQL, SQL에 대한 분석 정보(Parse Tree) 및 실행계획 저장
   5. Dictionary Cache
      • 테이블, 인덱스, 뷰, 함수 및 트리거 등의 사용자, 구조, 권한 등의 dictionary data 정보 저장
      • Row Cache : 참조 데이터를 row 단위로 가짐
   6. Reserved Area(예약 영역)
      • 크기가 큰 객체 저장
      • 동적 메모리 할당 시에 메모리 조각 부족으로 인한 SQL실행 실패(ORA-4031) 방지하기 위한 공간
   7. Spare Free Memory
      • 단편화 최소화를 위해 일정 크기를 고정 영역에 숨겨둠
      • 메모리 할당이 꼭 필요한 경우 이 영역에서 할당 받음
        !shared pool.jpg!

2. Library Cache 구성

1. 특징
   1. SQL문 수행과 관련된 모든 정보 저장
   2. LRU 알고리즘을 사용하여 관리(Database Buffer Cache와 공통점)
   3. shared pool latch : shared pool에서 특정 object 정보 혹은 SQL 커서를 위한 free chunk 할당 받을 때 필요
      • 9i 이전 : 하나의 shared pool latch로 전체 관리
      • 9i 이후 : shared pool을 여러 개의 sub pool로 나누어 관리할 수 있게되면서 latch도 7개까지 사용 가능
      • 동시 사용자가 순간적으로 과도한 하드파싱 부하를 일으킨다면 shared pool latch에 대한 경합 현상 발생 가능
2. 목적 : library cache에 저장된 정보를 빠르게 찾고 저장
3. Library Cache Object(LCO) : 라이브러리 캐시에 저장되는 정보의 단위
   1. Caching 정보 분류 I
      • Library Cache 안에서 공유되는 부분 : SQL 텍스트, Execution Plan, Bind Variable Data Type과 Length 등
      • 실행가능한 LCO : 실행가능
        • Package
        • Procedure
        • Function
        • Trigger
        • Anonymous PL/SQL Block (여기에 속하는게 맞는지?? @.@)
      • Object LCO : object 정보
        • Shared Cursor
        • Table Definition
        • View Definition
        • Form Definition
          {info:title=schema object information}
          1. data dictionary cache에도 저장됨(저장 포맷이 다름)
          2. library cache에도 저장하는 목적 : LCO간 의존성을 관리하기 위함
          {info}
   2. Caching 정보 분류 II

1. 작동 방법
   1. Heap Manager와 Library Cache Manager가 관리
   2. Library Cache Manager는 Hashing 기법 이용해서 Object에 대한 이름을 갖는 Handle을 찾고, 이 Handle은 다시 해당 Object를 가리킴
      {info:title=Handle(= Library cache Handel)}
      1. Library cache object(LCO) 관리
      2. 실제 정보가 있는 LCO에 대한 메타정보 및 위치값 저장
      3. SQL : SQL 텍스트를 상수로 변환해서 bucket결정
      4. SQL 이외(table, view etc) : "user + object name + DB link"를 상수로 변환해서 bucket결정
      {info}
   3. Library Cache Manager가 object 찾는 순서
      1. 필요한 Object의 Namespace, Object Name, Owner, Database Link 값에 Hash Function 적용
      2. 해당 Object가 존재하는 Hash Bucket 찾기 (SQL 문장의 경우 앞뒤 64바이트의 글자 이용)
      3. Hash Bucket의 Linked List를 따라 원하는 Object의 실제 존재 유무 체크
      4. Object 존재 : 찾은 Object를 사용
           Object 존재하지 않음 : Library Cache Manager는 주어진 이름으로 Empty Object 생성
      5. 생성된 Empty Object를 Hash Table에 포함시킴
      6. 오라클 프로세스에게 해당 Object를 로드하도록 요청
      7. 오라클 프로세스가 해당 Object를 디스크에서 읽어, Heap Manager에 의해 새로이 할당된 메모리에 올려놓음
      8. 해당 Object 사용
         {info:title=Child LCO}
          ⓐ SQL 커서 : 부모 LCO 밑에 schema 별로 자식 LCO소유. version count = 자식 LCO수
          ⓑ table, procedure etc : schema명과 함께 저장되므로 유일성이 보장되어 자식 LCO가 없음
         {info}
         
         
   4. SQL 문 찾는 순서
      • Bucket 찾기 : SQL 문에 Hash Function 적용 후 SQL 문의 Handle이 있는 Bucket 찾아감
      • 공유 가능한 SQL 문 찾기 : 해당 Bucket 안에는 다른 SQL 문이면서 Hash Function 값만이 같은 여러 SQL들이 있을 수 있으므로 이 Bucket List를 따라가면서 공유 가능한 같은 SQL이 있는지를 확인
      • 같은 문장을 발견하였지만 서로 다른 Version 존재 가능성 있음
        {info:title=Version}
        SQL 문은 같지만 서로 다른 유저의 Object를 사용한 경우, Bind Variable Data Type이 다른 경우, 서로 다른 Application Info를 사용하는 경우 서로 다른 Version으로 존재하며, 이는 공유되지 않는다.
        {info}
      • 같은 문장을 찾지 못한 경우는 SQL 문은 다시 Parsing 됨
        
2. Shared Pool Latch & Library Cache Latch
   1. Library Cache Latch : 라이브러리 캐시 체인을 탐색하고 변경할 때 획득
   2. latch:library cache 대기 이벤트 : Library Cache Latch 경합 발생 시
   3. Library Cache Latch 개수도 몇 개(CPU 개수에 근접)에 불과하므로 하드 파싱 및 소프트파싱이 많이 발생해도 이 latch에 대한 경합 증가 함
      
      
3. Library Cache Lock & Library Cache Pin
   1. 목적 : LCO 보호
   2. 순서 : handle Lock 획득 ⇒ Pin 획득 : LCO의 실제 내용이 담긴 heap에서 정보를 읽거나 변경 시
      • pin 획득 목적 : LCO를 읽고 쓰고, 실행하는 동안 다른 프로세스에 의해 정보가 변경되거나 캐시에서 밀려나는 것 방지

3. 라이브러리 캐시 최적화를 위한 개발자의 노력

1. 커서 공유 가능한 형태의 SQL 작성 : 바인드 변수 사용으로 하드파싱 감소
2. 세션 커서 캐싱 기능 활용 : 라이브러리 캐시에서 SQL 찾는 비용 감소
3. 에플리케이션 커서 캐싱 이용 : Parse Call 발생 감소

참고 문서

• 서적(오라클 성능 고도화 원리와해법 I)