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 | Front Page | 운영자 | 2010.05.17 | 154868 |
66 | 4. Prefetch | balto | 2010.07.10 | 28443 |
65 | 5. 오라클 Lock | 휘휘 | 2010.06.07 | 26368 |
64 | 2. DB 버퍼 캐시 | 휘휘 | 2010.05.24 | 21919 |
63 | 3. SQL 트레이스 | balto | 2010.06.06 | 21176 |
62 | 1. 기본 아키텍처 [1] | 휘휘 | 2010.05.23 | 19909 |
61 | 2. 트랜잭션 수준 읽기 일관성 | 휘휘 | 2010.06.07 | 19568 |
60 | 5. Undo | 토시리 | 2010.05.31 | 18663 |
59 | 11. Shared Pool | 실천하자 | 2010.05.31 | 18513 |
58 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.04 | 18347 |
57 | 4. Array Processing 활용 | 휘휘 | 2010.07.05 | 18252 |
56 | 1 장. 오라클 아키텍처 | 운영자 | 2010.05.20 | 17850 |
55 | 5. Fetch Call 최소화 | 휘휘 | 2010.07.05 | 16851 |
54 | 2. SQL 처리과정 | 휘휘 | 2010.06.28 | 15712 |
53 | 9. ASH(Active Session History) | 실천하자 | 2010.06.14 | 15608 |
52 | 3. 버퍼 Lock [1] | 휘휘 | 2010.05.24 | 15232 |
51 | 6. 바인드 변수의 부작용과 해법 | 실천하자 | 2010.06.28 | 14677 |
50 | 1. Explain Plan | 실천하자 | 2010.06.06 | 14666 |
49 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14031 |
» | 7. Result 캐시 | 휘휘 | 2010.07.19 | 12969 |