7. Result 캐시
2010.07.19 08:25
Result 캐시메모리
- Shared Pool 에 위치, 시스템 I/O발생량 최소화에 도움
- 한번수행한 쿼리 또는 PL/SQL 함수의 결과값을 Result 캐시에 저장(11g이상)
- SQL Query Resut 캐시
- SQL 쿼리 결과를 저장
- PL/SQL 함수 Result 캐시
- PL/SQL 함수 결과값을 저장
관련 파라미터
구분 | 기본값 | 설명 |
result_cache_mode | manual | Result 캐시 등록 방식을 결정
|
result_cache_max_size | N/A | SGA내에서 result_cache가 사용할 메모리 총량을 바이트로 지정 0 기능작동하지않음 |
result_cache_max_result | 5 | 하나의 SQL결과집합이 전체 캐시 영역에서 차지할수있는 최대 크기를 %로 지정 |
result_cache_remote_expiration | 0 | remote 객체의 결과를 얼마동안 보관할지를 분단위로 지정 0 저장하지 않음 |
- result_cache_max_size 가 명시되지않을 경우
- 11g 방식으로 SGA관리(SGA+PGA통합관리):
- memory_target으로 설정된 값의 0.25%를 Result캐시를 위해 사용
- 10g방식(sga_target 파라미터사용)
- 값의 0.5%를 Result캐시를 위해 사용
- shared_pool_size 수동설정
- 값의 1%를 Result캐시를 위해 사용
- 어떤방식이도 Result캐시는 Shared Pool의 75%가 넘지 않도록 관리됨
- SGA의 Shared Pool에 저장되어 모든세션에서 공유하고 인스턴스가 재기동하면 초기화됨
- 관련 래치
- Result Cache: Latch
- Result Cache: SO Latch
- Force 모드
- no_result_cache힌트를 사용하지 않은 모든 SQL대상
- Manual 모드
- result_cache힌트를 사용하여 사용
cf)
select /*+ RESULT_CACHE */ COL,COUNT(*)
from R_CACHE_TEST
where GUBUN=7
group by COL
- 처음실행시 104,332개의 블록 i/o 발생
- 사용현황확인 : v$result_cache_objects를 통해 확인
- 재수행시 0 블록 i/o가 나타남
- 쿼리 결과 집합을 캐싱하지 못하는 경우
- Dictionary 오브젝트를 참조할때
- Temporary 테이블을 참조할때
- 시퀀스로부터 CURRVAL,NEXTVAL Pseudo 컬럼을 호출할때
- 쿼리에서 아래 SQL 함수를 사용할때
- CURRENT_DATE
- CURRENT_TIMESTAMP
- LOCAL_TIMESTAMP
- SYS_CONTEXT(with non-constant variables_
- SYS_GUID
- SYSDATE
- SYSTIMESTAMP
- USERENV (with non-constant variables)
- 바인드변수를 사용할경우
- 변수값에 따라 개별적으로 캐싱이 이루어짐
- 캐시 엔트리 무효화
- 캐싱된 쿼리가 참조하는 테이블에 변경이 발생하는 순간 (두쿼리의 조인이라면 둘중 하나이상)
- 결과와 무관한 레코드를 삽입한 경우라도 무효
- 파티션테이블중 변경과 무관한 파티션을 참조하는 경우라도 무효
- 함수 Result 캐시역시 동일
- 함수 결과를 캐싱
create or replace function get_team_name (p_team_cd number)
return varchar2
RESULT_CACHE RELIES_ON (r_cache_function)
is
l_team_name r_cache_function.team_name%type;
begin
select team_name into l_team_name
from r_cache_function
where team_cd=p_team_cd;
return l_team_name;
end;
result_cache 옵션 사용, relies_on절에 지정된 테이블에 변경 발생할때 결과값 무효화됨
- 여러개의 쿼리 블록일 경우라도 특정 쿼리 블록만 캐싱 가능
인라인뷰select *
from r_cache_test t1,
(SELECT /*+ RESULT_CACHE */ ID FROM R_CACHE_TEST2
WHERE ID=1 ) t2
where t1.id=t2.idWITH 문
with wv_test
as (SELECT /*+ RESULT_CACHE MATERIALIZE */ SUM(ID) RNUM,ID
FROM R_CACHE_TEST
GROUP BY ID)
select *
from r_cache_test t1,
wv_test t2
where t1.id=t2.rnum
독립적 캐싱 (union all)
select sum(val)
from (select sum(c) val
from ext_stat_test
union all
select /*+RESULT_CACHE */ sum(id+sum_data)
from r_cache_test
)
where 절에 사용된 서브쿼리만 캐싱하는 기능은 제동하지 않음
- 사용이 유용한 경유
- 작은 결과 집합을 얻으려고 대용량 데이터를 읽어야 할때
- 읽기 전용의 작은 테이블을 반복적으로 읽어야 할때
- 읽기 전용 코드 테이블을 읽어 코드명칭을 반환하는 함수
- 사용을 자제해야할 경우
- 쿼리가 참조하는 테이블에 DML이 자조 발생할때
- 함수 또는 바인드 변수를 가진 쿼리에서 입력되는 값의 종류가 많고, 그값들이 골고루 입력될때
- 서버측 result 캐시와 별도로 클라이언트측 Result캐시기능도 제공됨
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
67 | 진행기록 | 운영자 | 2011.08.23 | 6588 |
66 | 3. Deterministic 함수 사용 시 주의사항 | 실천하자 | 2010.07.19 | 10593 |
65 | 6. RAC 캐시 퓨전 | 토시리 | 2010.07.19 | 12634 |
64 | 부록 | 휘휘 | 2010.07.19 | 7238 |
63 | 8. I/O 효율화 원리 | 휘휘 | 2010.07.19 | 7742 |
» | 7. Result 캐시 | 휘휘 | 2010.07.19 | 12970 |
61 | 2. Cursor_Sharing | balto | 2010.07.17 | 10216 |
60 | 1. Library Cache Lock | balto | 2010.07.17 | 12803 |
59 | 1. 블록 단위 I/O | 토시리 | 2010.07.12 | 9381 |
58 | 7. PL/SQL 함수의 특징과 성능 부하 | 실천하자 | 2010.07.12 | 12608 |
57 | 3. Single Block vs. Multiblock I/O | 휘휘 | 2010.07.12 | 9172 |
56 | 2. Memory vs. Disk I/O | 휘휘 | 2010.07.12 | 7439 |
55 | 6. 페이지 처리의 중요성 | 실천하자 | 2010.07.11 | 6820 |
54 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14031 |
53 | 5. Direct Path I/O | balto | 2010.07.10 | 12192 |
52 | 4. Prefetch | balto | 2010.07.10 | 28445 |
51 | 6장. I/O 효율화 원리 | 휘휘 | 2010.07.08 | 6404 |
50 | 3. 데이터베이스 Call이 성능에 미치는 영향 | 토시리 | 2010.07.07 | 11667 |
49 | 2. User Call vs. Recursive Call | 토시리 | 2010.07.07 | 9050 |
48 | 5장. 데이터베이스 Call 최소화 원리 | 휘휘 | 2010.07.05 | 6103 |