<11/22> 상심

Shared Pool - 한번 처리된 SQL의 실행 정보를 공유함으로써 자원의 사용 최소화 및 SQL 수행 속도 증가

Variable Area : Shared Pool +  JAVA Pool + Large Pool + Streams Pool

커서는 DML 구문을 위한 메모리에 대한 핸들(이름 또는 포인터)이다

Permanent Area(시스템 / 고정 영역)

 - SGA 관리 메커니즘 및 오라클 파라미터 정보 저장

 - 자동할당 .  사용자 지정 x

 - SGA 구성 요소 중 Fixed Size에 해당

Library Cache

 - PL/SQL / SQL에 대한 분석 정보(Parse Tree ) 및 실행계획 저장

Dictionary Cache

 - 테이블 인덱스 뷰 함수 및 트리거 등의 사용자 구조 권한 등의 딕셔너리 데이터 정보 저장

 - Row Cache : 참조 데이터를 row 단위로 가짐

Reserved Area ( 예약 영역)

 - 크기가 큰 객체 저장

 - 동적 메모리 할당 시에 메모리 ㅈ각 부족으로 인한 SQL 실행 실패(ORA-4031) 방지 위한 공간

Spare Free Memory

 - 단편화 최소화를 위해 일정 크기를 고정 영역에 숨겨둠

 - 메모리 할당이 꼭 필요한 경우 이 영역에서 할당 받음

라이브러리캐시에 저장되는 정보의 단위를 LCO라고 하는데 이것은 Heap Manager와 Labrary Cache Manager가 관리한다 라이브러리 캐시 매니저는 해싱 기법을 이용해서 오브젝트에 대한 이름을 갖는 핸들을 찾고 이 핸들은 다시 해당 오브젝트를 가리킨다

Handle(=Library cache Handle)

 - LCO 관리

 - 실제 정보가 있는 LCO에 대한 메타정보 및 위치값 저장

 - SQL : SQL 텍스트를 상수로 변환해서 버킷 결정

 - SQL 이외(table, view etc) : "user + object name + DB link를 상수로 변환해서 버킷 결정

Library Cache Manager가 object를 찾는 순서

1. 필요한 오브젝트의 namespace, Object Name, Owner, Database Link 값에 Hash Function 적용

2. 해당 오브젝트가 존재하는 해시 버킷 찾기(SQL 문장의 경우 앞뒤 64바이트의 글자 이용)

3. 해시 버킷의 linked list를 따라 원하는 Object의 실제 존재 유무 체크

4. 오브젝트 존재 O : 찾은 오브젝트 이요

   오브젝트 존재 X : Library Cache Manager는 주어진 이름으로 Empty Object 생성

5. 생성된 Empty Object를 Hash Table에 포함시킴

6. 오라클 프로세스에게 해당 오브젝트를 로드하도록 요청

7. 오라클 프로세스가 해당 오브젝트를 디스크에서 읽어 Heap Manger에 의해 새로이 할당된 메모리에 올려놓음

8. 해당 오브젝트 이용

Child LCO

 - SQL 커서 : 부모 LCO 밑에 스키마 별로 자식 LCO 소유 version count = 자식 LCO 수

 - table, procedure etc : 스키마명과 함께 저장되므로 유일성이 보장되어 자식 LCO가 없음

SQL문 찾는 순서

 - 버킷 찾기 : SQL 문에 해시 함수 적용 후 SQL 문의 핸들이 있는 버킷 찾아감

 - 공유 가능한 SQL 문 찾기 : 해당 버킷 안에는 다른 SQL문이면서 해시 함수값만이 같은 여러 SQL들이 있을 수 있으므로 이 버킷 리스트를 따라가면서 공유 가능한 같은 SQL문이 있는지를 확인

 - 같은 문장을 발견하였지만 서로 다른 Version 존재 가능성 있음

Version?

- SQL 문은 같지만 서로 다른 유저의 오브젝트를 사용하는 경우, Bind Variable Data Type이 다른 경우 , 서로 다른 Application Info를 사용하는 경우 서로 다른 Version으로 존재하며 이는 공유되지 않는다.

 - 같은 문장을 찾지 못한 경우는 SQL 문은 다시 Parsing 됨

Shared Pool Latch & Library Cache Latch

 - LIbrary Cache Latch : 라이브러리 캐시 체인을 탐색하고 변경할 때 획득

 - Latch : LIbrary Cache 대기 이벤트 : 라이브러리 캐시 래치 경합 발생 시

 - Library Cache Latch 개수도 몇 개(CPU 개수에 근접)에 불과하므로 하드 파싱 및 소프트파싱이 많이 발생해도 이 래치에 대한 경합 증가함

Library Cache Lock & Library Cache Pin

 - 목적 : LCO 보호

 - 순서 : handle Lock 획득 => Pin 획득 : LCO의 실제 내용이 담긴 heap에서 정보를 읽거나 변경 시

   *pin 획득 목적 : LCO를 읽고 쓰고 실행하는 동안 다른 프로세스에 의해 정보가 변경되거나 캐시에서 밀려나는것 방지

Shared Pool Latch & Library Cache Latch 경합	Library Cache Lock & Library Cache Pin 대기 이벤트
소프트 / 하드 파싱을 동시에 심하게 일으킬 때 발생	1. SQL 수행 도중 DDL 문 실행 시 발생 2. 트랜잭션이 활발할 때 DDL 문을 실행하면 데이터베이스 오브젝트 정의를 변경하게 되고 라이브러리 캐시에 심한 부하 발생 3. 파싱 과정에서 경합 발생하면 각각 latch:library cache(soft)  latch : shared pool(hard)이벤트를 대기 4. 하드 파싱 : 새로운 커서를 생성해서 라이브러리 캐시 체인 길이가 증가되어 검색 시간이 증가되므로 성능저하

라이브러리 캐시 최적화를 위해 필요한 노력

 - 커서 공유 가능한 형태의 SQL 작성 : 바인드 변수 사용으로 하드파싱 감소

 - 세션 커서 캐싱 기능 활용 : 라이브러리 캐시에서 SQL 찾는 비용 감소

 - 에플리케이션 커서 캐싱 이용 : Parse Call 발생 감소

참조 : http://wiki.gurubee.net/pages/viewpage.action?pageId=4948304