RESULT 캐시

• Result 캐시는 버퍼 캐시에 위치하지 않고 Shared Pool에 위치
• 한번 수행한 쿼리 또는 PL/SQL 함수의 결과값을 Result 캐시에 저장해 두는 기능을 11g 버전부터 제공

• 대용량 데이터 쿼리라면 집계테이블을 따로 설계하거나 Materialized View를 생성하는 것 외에 별다른 방법이 없다.

1. DML이 거의 발생하지 않는 테이블을 참조하면서
2. 반복 수행 요청이 많은 쿼리

Result 캐시 메모리는 다음 두 가지 캐시 영역으로 구성

1. SQL Query Result 캐시 :SQL 쿼리 결과를 저장
2. PL/SQL 함수 Result 캐시 : PL/SQL 함수 결과값을 저장

Result 캐시를 파라미터

• result_cache_max_size 규칙 ( 관리자가 지정하지 않는경우 )
  • 11g - memory_target의 0.25%를 Result캐시를 위해 사용 ( SGA와 PGA를 통합 )
  • 10g - sga_target의 0.5%를 Result캐시를 위해 사용 ( SGA )
  • 기타- shared_pool 의 1를 Result캐시를 위해 사용
  • 최소값은 0 : disable된다.
  • 최대값 : shared pool크기의 75%이다.

Result 캐시 Manual 모드

 
SELECT /*+ RESULT CACHE */ COL， COUNT(*)
  FROM R_CACHE_TEST
 WHERE GUBUN = 7
 GROUP BY COL

• 반대의 경우는 /*+no_result_cache*/

• 힌트가 지정된 쿼리를 수행할 때 오라클 서버 프로세스는 Result 캐시 메모리를 먼저 찾아보고, 캐싱돼 있다면 그것을 가져다가 결과 집합을 리턴

Result 캐시 TEST

• 최초의 쿼리 결과
  

• 수행한 쿼리의 캐싱 여부
  

• 캐싱된 쿼리 결과
  

h5.캐싱 안하는경우( 제약 사항)

• Dictionary나 Temporary 테이블의 경우
• Currval이나 Nextval과 같이 Sequence 컬럼이 들어가 있는 경우
• SQL function중 sysdate, current_date, userenv/sys_context(변수로 상수가 아닌경우), local_timestamp, current_timestamp, sys_guid, sys_timestamp등 가변적인 결과값을 사용하는 경우
• 바인드 변수를 사용한 경우는 변수만 같다면 cache가 가능 ( 바인드 변수의 종류가 다양하면 캐시의 효율성이 떨어짐 )
• 서브 쿼리

캐싱 무효

• 캐싱된 쿼리가 참조히는 테이블에 변경이 발생하면 해당 캐시 엔트리를 무효됨
• 쿼리에서 두 태이블을 참조한다면, 둘중 하나에 DML이 발생하는 순간 캐싱된 결과 집합이 무효
• 참조된 테이블에 DML이 발생하면 무효 ( 캐싱과 상관없는 ROW 라도 )

특정 쿼리 블록만 캐싱

• 캐싱되는 경우
  

• 캐싱 안되는 경우
  

효과적인 캐싱 상황

• 작은 결과 집합을 얻으려고 대용량 데이터를 읽어야 할 때
• 읽기 전용의 작은 테이블을 반복적으로 읽어야할때
• 읽기 전용 코드 테이블을 읽어 코드명칭을 반환하는 함수