<오라클 성능 고도화 원리와 해법1> Ch01-11 Shared Pool

오라클 성능 고도화 원리와 해법1 Ch01 오라클 아키텍처 - 11 Shared Pool

이제 SGA의 가장 중요한 구성 요소 중 하나인 Shared Pool에 대해 간단히 살펴보자. (간단히 설명하는 이유는 중요성이 떨어지기 때문이 아니라 너무 중요한 내용이어서 뒤에서 더 자세히 다루려는 것이다.)

(1) 딕셔너리 캐시

Shared Pool은 크게 딕셔너리 캐시(Dictionary Cache)와 라이브러리 캐시(Library Cache)로 나뉜다. 우선 딕셔너리 캐시에 대해 설명하면, 말 그대로 오라클 딕셔너리 정보를 저장해두는 캐시 영역으로서 Row 단위로 읽고 쓰기 때문에 ‘로우 캐시(Row Cache)’라고도 불린다. 테이블, 인덱스 같은 오브젝트는 물론 테이블스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약, Sequence, DB Link에 관한 정보들을 캐싱한다.

Sequence Cache 옵션
잦은 채번은 로우 캐시에 경합을 발생시키게 된다. 이를 해소하기 위해 필수적으로 Cache 옵션을 사용해야 하며, Cache 크기가 10이면 No cache 일 때보다 로우 캐시를 갱신하는 횟수가 1/10로 준다. 동시에 채번이 많이 발생하는 Sequence일수록 cache 사이즈를 크게 설정하는 것은 매우 중요한 튜닝 요소 중 하나이며, 기본 설정값은 20이다.

딕셔너리 캐시의 활동성에 대한 통계를 조회해볼 수 있는 뷰가 v$rowcache인데, 여기서 히트 레이션(Hit Ratio)을 조사했을 때 수치가 낮게 나오면 Shared Pool 사이즈를 늘리는 것을 고려해볼 필요가 있다.

즉, 로우 캐시에 관리되는 엔트리 각각에 대해 하나의 래치가 할당돼 있음을 짐작할 수 있다.

(2) 라이브러리 캐시

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

쿼리 구문을 분석해서 문법 오류 및 실행 권한 등을 체크하고, 최적화 과정을 거쳐 실행 계획을 만들고, SQL 실행 엔진이 이해할 수 있는 형태로 포맷팅하는 전 과정을 하드 파싱(Hard Parsing)이라고 한다. 특히 최적화(optimization)는 하드 파싱을 무겁게 만드는 가장 결정적 요인인데, 같은 SQL을 처리하려고 이런 무거운 작업을 반복 수행하는 것은 매우 비효율적이다. 그래서 같은 SQL에 대한 반복적인 하드 파싱을 최소화하기 위한 새로운 캐시 공간을 두게 되었고, 그것이 바로 라이브러리 캐시 영역이다. 당연히 라이브러리 캐시 최적화 원리는 캐싱된 SQL과 그 실행 계획의 재사용성을 높이는 데에 있다.

라이브러리 캐시 최적화 원리에 대해서는 뒤에서 아주 자세히 다루므로 여기서는 이 정도 개념만 이해하고 넘어가도록 하자.