shared pool

WORKSHOP : SHARED POOL

CONCEPT
 SGA를 관리하는 매커니즘, 파라메터 정보, 실행된 SQL, SQL 분석/ 실행 정보 및 오라클 오브젝트 정보를 저장하는 메모리 공간.동적 영역과 고정 영역으로 분리됨.

 동적영역 - SHARED_POOL_SIZE 파라메토를 사용하여 설정 가능
  LIBRARY CACHE
   - 사용자가 수행한 SQL
   - Recursive SQL
   - 분석정보
   - 실행계획

  DICTIONARY CACHE
   - Table, Index, Function, Trigger 등 오브젝트 정보 및 권한등의 정보

 고정영역
  SGA를 관리하는 메커니즘 및 오라클 파라메터 정보 저장.
  SHOW SGA 명령으로 나오는 Fixed Size 의 값이 고정 영역의 크기.


PARAMETERS
 SHARED_POOL_SIZE
  Shared pool 의 크기를 결정한다.

 SHARED_POOL_RESERVED_SIZE
  4400 Bytes 이상의 SQL 이 수행될 경우 이 공간이 충분하지 않다면,  ORA-4031 발생한다. 해당 예약 공간을 설정하지 않으면 기본적으로 Shared pool 의 5%가 할당되고 최대 Shared pool 의 50% 이상 설정할 수 없다.


ORA-4031. Unable to Allocate %s Bytes of shared memory
 SQL 정보를 저장할 수 있는 충분한 크기의 사용 가능 메모리 조각이 부작할 시 발생한다. 이때 다음의 방법을 통해 이 문제를 해결할 수 있다.

 ALTER SYSTEM FLUSH SHARED_POOL;
  Shared Pool 의 모든 내용을 초기화 한다. 하지만 다시 들어오는 SQL문은 다시 새로이 Hard Parsing 이 수행되므로 부하가 순간 발생할 수 있다.

 SHARED_POOL_RESERVED_SIZE 파라메터 값 증가.

 LARGE POOL 설정.



PARSE
 오라클은 사용자가 SQL 구문을 수행하면 그 SQL을 분서갛여 실행할 수 있는 단계를 만든다. SOFT PARSING 과 HARD PARSING 이 존재하며 SOFT PARSING 은 이미 SHARED POOL에 저장되어 있는 정보를 재사용하는 것이며, HARD PARSING 은 재사용하지 못하고 다시 구문 분석을 수행하게 된다(부하 높음).

 하드 파싱을 피하기위해서는 다음 사항을 준수한다.
  - 대소문자 일치
  - 띄어쓰기 일치
  - 오브젝트 소유자 일치





SHARED POOL 의 메모리 관리
 SHARED POOL 은 HEAP 이라는 메모리 관리 기법으로 관리한다. HEAP 은 Top-Level Heap 과 그 하위에 여러개의 Sub-Heap 으로 구분하고 또 Heap은 Linked List 구조의 EXTENT 들로 구성되어져 있으며 Extent는 여러개의 chunk 로 구성되어 있다.





SHARED POOL HEAP 구조도

 Bucket
  각각의 정해진 기준의 크기 이하의 chunk 들로만 구성. Bucket 이 아래로 갈수록 chunk들의 크기가 크다.

 Recreatable
  재생성 가능한 상태.  Unpinned (사용되지 않는 상태) 일 때 재사용 가능. 즉, 이미 한번 사용되었지만, 다시 사용될 확율이 낮아져서 재사용이 가능한 상태가 된 것. 이러한 상태의 Chunk를 묶어 LRU List로 관리한다.  ( X$KGHLU )

 Freeable
  Session 이나 Call 동안에만 필요한 객체를 저장하고 있는 상태. Session 의 유지 시간은 알 수 없으므로, Chunk 가 필요할때 할당의 대상이 되지는 않는다.

 Permanent
  영구적인 객체를 저장하고 있으며 사용할 수 없는 Chunk 이다.



SHARED POOL 의 메모리 관리
 Free List 검색후 Free List에 사용할 공간이 부족하면 LRU List 를 탐색한다. 그래도 공간이 없으면 Reserved Free List 를 탐색하고 없으면 Space Free Memory탐색. 없으면 ORA - 4031.

 Oracle 9i 부터는 하나의 Shared pool 을 최대 7개까지의 Sub pool 로 나누어서 관리를 수행한다.  Hidden Parameter 인 "_KGHDSIDX_COUNT" 를 이용하여 하나의 SHARED POOL 을 나누어 관리한다.  CPU 4개에 SHARED_POOL_SIZE 가 250메가 이상일 시 Sub Pool 사용을 권고한다.  각각의 Sub pool 당 독다적인 Free List, LRU List, Shared pool latch를 가지기 때문에 부족한 자원에 대한 경합을 감소시킬 수 있으나 CPU 개수나 SHARED_POOL_SIZE 의 크기가 충분하지 않으면 ORA-4031을 발생할 수 있다.



LIBRARY CACHE
 라이브러리 캐시는 Hash function, Bucket, Handle list, LCO 로 구성되어 있다. Library Cache Manager (KGL) 에 의해 관리되고 내부적으로 Heap Manager (KGH) 를 이용한다.  할당된 Free Chunk 는 LCO(Library Cache Object) 와 handle 을 저장하는데 사용된다.

 동일 Hash 값으로 이루어진 Handle 들은 linked list 로 Hash Bucket 에 담긴다. 추후 SQL문이 들어오면 Hash function 을 이용해 나온 값이 동일한 값을 가진 Handle  이 있는지를 찾게 된다.  Handle 은 크게 Name (SQL Text) 와 Meta 정보로 이루어져 있다. 이를 LCO (Library Cache Object) 라고 부른다.

  DEPENDENCY TABLE
 해당 LCO가 의존하는 LCO들의 Handle 포인트와 해당 LCO 가 뷰를 포함하고 있다면, 뷰에서 참조하는 Source Table 에 대한 Library Cache Handle 주소를 나타내며 해당 LCO가 패키지일 경우 패키지에서 사용하고 있는 펑션이나 프로시져에 대한 Library Cache Handle 주소를 가진다.  해당 LCO 가 SQL 문장일 경우 SQL 문에서 참조하는 테이블에 대한 Library Cache Handle 주소를 가지게 된다.  (V$DB_OBJECT_DEPENDENCY  :  Shared Pool의 Dependency 정보 확인)

 CHILD TABLE
 동일 SQL문장에 대하여 VERSION COUNT 가 증가 한 경우 각각의 LCO에 대한 주소 값을 나타낸다. VERSION COUNT 가 증가하는 경우는 동일 쿼리지만 SCHEMA 가 다르거나,  SQL  수행시의 파라메터가 다르거나, NLS 값이 틀리거나 하는 등의 이유가 있을 수 있다. 정확히 알기 위해서는 V$SQL_SHARED_CURSOR 뷰를 참조.

 SQL TEXT 등을 해시 함수를 적용해 생성된 해시값을 이용해 적절한 해시 버킷을 할당하며, 같은 해시 값을 지니는 객체들은 체인으로 관리된다. 하나의 라이브러리 캐시 핸들은 하나의 라이브러리 캐시 오브젝트 ( LCO)를 관리한다. 핸들은 실제 LCO 에 대한 메타정보 및 포인터 역할을 하며 LCO가 실제 정보를 담고 있다.



LIBRARY CACHE CONTENTION
 Hard Parsing 이 자주 발생하게 되면 그만큼 Library Cache 를 탐색하는 횟수가 늘어나 Library Cahce Latch 를 보유하는 시간과 횟수가 늘어나게 된다.
 (Library Cache Latch - 간단히 Library Cache 를 사용할 수 있는 권한 증명서)
 Hard Parsing 은 Library Cache 영역에 대한 탐색 뿐만 아니라 추가적인 Chunk 할당이 필요하기에 그만큼 Library Cache Latch를 보유하는 시간이 늘어나게 된다.



DICTIONARY CACHE
 SEVER PROCESS 가 쿼리를 수행하기 위해 해당 쿼리의 문법검사, 권등을 체크하기 위해 참조하는 캐시이다.  일반적인 데이터베이스 정보를 저장하고 있는 캐시.
 DICTIONARY VIEW 는 4가지 형태로 나뉘어져 있다.

  USER_
   해당 스키마가 소유한 객체들
  ALL_
   해당 스키마가 접근 가능한 모든 객체
  DBA_
   DBA만이 접근 가능한 정보로써, DB의 정보를 포함
  V$_
    DB의 성능정보를 보는 동적 성능뷰 (Performance View)