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 라도 )
특정 쿼리 블록만 캐싱
  • 캐싱되는 경우
  • 캐싱 안되는 경우
효과적인 캐싱 상황
  • 작은 결과 집합을 얻으려고 대용량 데이터를 읽어야 할 때
  • 읽기 전용의 작은 테이블을 반복적으로 읽어야할때
  • 읽기 전용 코드 테이블을 읽어 코드명칭을 반환하는 함수