Shared Pool
(1) 딕셔너리 캐시
- 오라클 딕셔너리 정보를 저장해 두는 캐시영역으로서 Row단위로 읽고 쓰기 때문에 '로우 캐시' 라고도 불린다.
- 테이블, 인덱스, 테이블스페이스, 테이터파일, 세그먼트, 익스텐트, 사용자, 제약, Sequence, DB Link에 관한 정보를 캐싱한다.
- 딕셔너리 캐시의 활동성에 대한 통계를 조회해 볼 수 있는 뷰가 v$rowcache인데 여기서 히트를 조사했을 때 수치가 낮게 나오면 Shared Pool 사이지를 늘리는 것을 고려해 볼 필요가 있다.
{CODE:SQL}
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
{CODE}
- V$ROWCACHE 에서 TYPE = 'PARENT'인 엔트리와 V$LATCH_CHILDREN 에서 row cache objects 인 래치 개수를 조회해 보면, 항상 값이 일치하는 것을 알 수 있다.
로우 캐시에 관리되는 엔트리 각각에 대해 하나의 래치가 할당돼 있음을 있음을 짐작 할 수 있다.
{CODE:SQL}
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
{CODE}
(2) 라이브러리 캐시
- DB 버퍼 캐시, Redo 로그 버퍼 캐시, 딕셔너리 캐시 등은 데이터의 입출력을 빠르게 하기 위한 캐시영역인 반면 라이브러리 캐시는 사용자가 던진 SQL과
그 실행 계획을 저장해 두는 캐시영역이다. 사용자가 SQL이라는 명령어를 통해 결과집합을 요청하면 이를 최적으로수행하기 위한 처리 루틴이 필요한데,
이걸 실행 계획이라고 한다. 빠른 쿼리 수행을 위해 내부적으로 생성한 일종의 프로시저오 같은 것이라고 이해하면 쉽다
하드파싱
- 1. 쿼리 구문을 분석
- 2. 문법 오류 및 실행 권한 등을 체크
- 3. 최적화 과정을 거쳐 실행계획 생성 - 최적하는 하드 파싱을 무겁게 만드는 가장 결정적인 요인
- 4. SQL 실행엔진이 이해할 수 있는 형태로 포맷팅
소프트파싱
- 같은 SQL을 처리하려고 이런 무거운 작어블 반복 수행하는 것은 매우 비효율적이다.
그래서 같은 SQL에 대한 반복적인 하드파싱을 최소화하기 위한 새로운 캐시 공간을 두게 되었고,
그것이 바로 라이브러리 캐시 영역이다. 당연히 라이브러리 캐시 최적화 원리는 캐싱된 SQL과
그 실행계획의 재사용성을 높이는데 있다.