꿈꾸는 개발자, DBA 커뮤니티 구루비

Shared Pool
1. (1) 딕셔너리 캐시
2. (2) 라이브러리 캐시

Shared Pool

(1) 딕셔너리 캐시

오라클 딕셔너리 정보를 저장해 두는 캐시영역으로서 Row단위로 읽고 쓰기 때문에 '로우 캐시' 라고도 불린다.
테이블, 인덱스, 테이블스페이스, 테이터파일, 세그먼트, 익스텐트, 사용자, 제약, Sequence, DB Link에 관한 정보를 캐싱한다.
딕셔너리 캐시의 활동성에 대한 통계를 조회해 볼 수 있는 뷰가 v$rowcache인데 여기서 히트를 조사했을 때 수치가 낮게 나오면 Shared Pool 사이지를 늘리는 것을 고려해 볼 필요가 있다.


SQL>  SELECT ROUND( SUM(GETS - GETMISSES) / SUM(GETS) * 100, 2) HIT_RATIO 
  2   FROM V$ROWCACHE;

 HIT_RATIO
----------
     99.18

SQL>  SELECT PARAMETER
  2            , GETS
  3            , GETMISSES
  4            , ROUND((GETS-GETMISSES)/ GETS * 100, 2) HIT_RATIO
  5            , MODIFICATIONS
  6    FROM V$ROWCACHE
  7  WHERE GETS > 0
  8  ORDER BY HIT_RATIO DESC;

PARAMETER                              GETS  GETMISSES  HIT_RATIO MODIFICATIONS
-------------------------------- ---------- ---------- ---------- -------------
dc_tablespaces                      5869348         17        100             0
dc_awr_control                       203615          1        100          6288
dc_profiles                          186541          1        100             0
dc_users                            8288476        102        100             9
dc_rollback_segments                3797577         36        100            23
dc_usernames                         821290         74      99.99             0
dc_global_oids                      1151936        239      99.98             0
dc_users                             202051         65      99.97             0
dc_histogram_data                   1265253       1227       99.9             0
dc_files                               7560         14      99.81             0
dc_object_ids                       9380099      18851       99.8          6869

PARAMETER                              GETS  GETMISSES  HIT_RATIO MODIFICATIONS
-------------------------------- ---------- ---------- ---------- -------------
dc_segments                         3199432       8966      99.72         32545
dc_sequences                           9087         42      99.54          9087
dc_objects                          4789191      28512       99.4         39237
dc_database_links                      1422         12      99.16             0
dc_histogram_data                   5266470      50773      99.04          7865
dc_histogram_defs                   9291607     273007      97.06         34122
dc_tablespace_quotas                    107          4      96.26           107
dc_object_grants                      14766        596      95.96             0
outstanding_alerts                   716191      63949      91.07        127833
dc_constraints                           48         17      64.58            48
dc_table_scns                            19         19          0             0

V$ROWCACHE 에서 TYPE = 'PARENT'인 엔트리와 V$LATCH_CHILDREN 에서 row cache objects 인 래치 개수를 조회해 보면, 항상 값이 일치하는 것을 알 수 있다.
로우 캐시에 관리되는 엔트리 각각에 대해 하나의 래치가 할당돼 있음을 있음을 짐작 할 수 있다.


SQL>  SELECT *
  2    FROM (SELECT COUNT(*) FROM V$ROWCACHE WHERE TYPE = 'PARENT' )   
  3      , (SELECT COUNT(*) FROM V$LATCH_CHILDREN WHERE NAME = 'row cache objects')
  4  ;

  COUNT(*)   COUNT(*)
---------- ----------
        34         34

(2) 라이브러리 캐시

DB 버퍼 캐시, Redo 로그 버퍼 캐시, 딕셔너리 캐시 등은 데이터의 입출력을 빠르게 하기 위한 캐시영역인 반면 라이브러리 캐시는 사용자가 던진 SQL과 그 실행 계획을 저장해 두는 캐시영역이다.
사용자가 SQL이라는 명령어를 통해 결과집합을 요청하면 이를 최적으로수행하기 위한 처리 루틴이 필요한데, 이걸 실행 계획이라고 한다.
빠른 쿼리 수행을 위해 내부적으로 생성한 일종의 프로시저오 같은 것이라고 이해하면 쉽다

하드파싱

1. 쿼리 구문을 분석
2. 문법 오류 및 실행 권한 등을 체크
3. 최적화 과정을 거쳐 실행계획 생성 - 최적하는 하드 파싱을 무겁게 만드는 가장 결정적인 요인
4. SQL 실행엔진이 이해할 수 있는 형태로 포맷팅

소프트파싱

같은 SQL을 처리하려고 이런 무거운 작어블 반복 수행하는 것은 매우 비효율적이다.
그래서 같은 SQL에 대한 반복적인 하드파싱을 최소화하기 위한 새로운 캐시 공간을 두게 되었고, 그것이 바로 라이브러리 캐시 영역이다.
당연히 라이브러리 캐시 최적화 원리는 캐싱된 SQL과 그 실행계획의 재사용성을 높이는데 있다.