Result Cache 관련 latch는 result cache 에 데이터가 있고 , 그 상태에서 해당 정보에 접근하기 위하여 획득하여야 한다는 것을 전 포스트에서 확인 할 수 있었다.
이번에는 result cache관련 다른 이벤트인 Enq : RC – Result Cache : Contention에 대해서 확인 해 보도록 하자.
다음 쿼리를 이용하여 Result Cache관련 추가된 이벤트가 무엇이 있는지 확인 할 수 있다.
|
11:28:50 HR 5036>SELECT name , wait_class , PARAMETER1 ,PARAMETER2 ,PARAMETER3 FROM v$event_name WHERE name like '%Result%' ;
NAME WAIT_CLASS PARAMETER1 PARAMETER2 PARAMETER3
--------------------------------- -------------- --------------- --------------- -------------- enq: RC - Result Cache: Contention Application name|mode chunkNo blockNo
|
해당 enqueue가 몇 번이나 발생 하였는지는 v$enque_stat 뷰를 확인 하면 알 수 있다. 그럼 어떠한 경우에 해당 enqueue의 요청이 있는지 확인해 보도록 하자.
테스트를 위해서 데이터 베이스를 Restart한 후 테스트를 진행 해 보았다.
|
14:09:23 HR 6805>SELECT * FROM v$result_cache_objects ;
no rows selected
14:09:32 HR 6805>SELECT * FROM v$enqueue_stat WHERE eq_type = 'RC' ;
No rows selected
|
위와 같이 조회를 해 보면 아직 RC enqueue가 사용되지 않음을 확인 할 수 있다.
- Test Case#1
Result cache에 등록된 데이터는 없는 상태이다. 새로운 Result 데이터를 등록해 본 후 Enqueue 요청을 확인해 보자.
|
14:12:10 HR 6805>select /*+ result_cache */ count(*) from test_rc ;
COUNT(*)
----------
103
14:12:24 HR 6805>set autotrace on exp stat
14:12:36 HR 6805>select /*+ result_cache */ count(*) from test_rc ;
COUNT(*)
----------
103
Execution Plan
----------------------------------------------------------
Plan hash value: 1775316367
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
| 1 | RESULT CACHE | 3dhb1js3x6ghf0zdkxtn6cwvsp
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| TEST_RC | | 103 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=1; dependencies=(HR.TEST_RC); attributes=(single-row); name="select /*+ result_cache */ count(*) from test_rc "
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
419 bytes sent via SQL*Net to client
420 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
14:12:43 HR 6805>SELECT name , type , scan_count , object_no , invalidations FROM v$result_cache_objects ;
NAME TYPE SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ ------------ ------------- ------------ ----------------
HR.TEST_RC Dependency 0 76779 0
select /*+ result_cache */ cou Result 1 0 0
nt(*) from test_rc
14:16:32 HR 6805>SELECT * FROM v$enqueue_stat WHERE eq_type = 'RC' ;
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 2 0 2 0 0
|
위의 테스트 결과를 보면 Total_req# 이 2번 있고 Succ_req# 값이 2 이다. 즉 두번의 RC enqueue 요청이 있었고 두번의 요청이 모두 성공적으로 enqueue를 획득 하였다는 뜻이다.
-Test Case#2
latch 와 마찬가지로 result cache관련 조회 시 Enqueue요청이 증가 하는지 확인해 보도록 하자.
|
14:19:15 HR 6805>select /*+ result_cache */ count(*) from test_rc ;
COUNT(*)
----------
103
Execution Plan
----------------------------------------------------------
Plan hash value: 1775316367
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
| 1 | RESULT CACHE | 3dhb1js3x6ghf0zdkxtn6cwvsp |
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| TEST_RC | | 103 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
75 recursive calls
0 db block gets
14 consistent gets
8 physical reads
0 redo size
419 bytes sent via SQL*Net to client
420 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
14:21:48 HR 6805>SELECT * FROM v$enqueue_stat WHERE eq_type = 'RC' ;
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 2 0 2 0 0
|
Result Cache를 사용할 때는 Enqueue에 대한 요청이 발생하지 않음을 확인 할 수 있다.
-Test Case#3
기존의 Result cache 데이터를 변경하기 위해서 test_rc테이블에 대하여 DML을 발생 시킨 후 RC enqueue가 변화 하는지 확인해 보도록 하자
|
- Check.sql
SELECT name , type , scan_count , object_no , invalidations FROM v$result_cache_objects ; SELECT * FROM v$enqueue_stat WHERE eq_type = 'RC' ;
|
|
14:27:02 HR 6805>insert into test_rc values ( 104, 'N 104') ;
1 row created.
14:28:35 HR 6805>@check
NAME TYPE SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ ------------ ------------- ------------ ----------------
HR.TEST_RC Dependency 0 76779 0
select /*+ result_cache */ cou Result 2 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 2 0 2 0 0
14:29:53 HR 6805>commit ;
14:30:21 HR 6805>@check
NAME TYPE SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ ------------ ------------- ------------ ----------------
HR.TEST_RC Dependency 0 76779 1
select /*+ result_cache */ cou Result 2 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 3 0 3 0 0
|
Result Cache를 Invalidation 시켜 보기 위해서 데이터를 변경 시킨 후에 v$result_cache_objects , v$enqueue_stat뷰를 조회해 보면 Dependency 테이블이 invalidation되면서 RC enqueue 요청이 한번 있었다. 새로운 Result를 Caching 시키기 위해서는 Dependency에 한번 쿼리와 연관된 부분을 참조 하기 위해서 한번 이렇게 두 번의 요청이 있었고 , Dependency 부분에 대한 변경을 가할 경우 RC Enqueue 요청이 한번 있음을 확인 할 수 있다.
- Test Case#3
Dependency 가 존재 하는 상태에서 새로운 쿼리 Result 등록시에 RC Enqueue 요청이 몇 번 일어날까 ?
|
14:36:32 HR 6805>SELECT /*+ result_cache */ max(empno) FROM test_rc ;
MAX(EMPNO)
------------
105
Execution Plan
----------------------------------------------------------
Plan hash value: 1775316367
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1 | 13 | 3 (0)| 00:00:01 |
| 1 | RESULT CACHE | 93dajfjcxpd1t5474wnnz6kzjb
| 2 | SORT AGGREGATE | 1 | 13 | | |
| 3 | TABLE ACCESS FULL| TEST_RC | 104 | 1352 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=1; dependencies=(HR.TEST_RC); attributes=(single-row); name="SELECT /*+ result_cache */ max(empno) FROM test_rc "
Statistics
----------------------------------------------------------
183 recursive calls
0 db block gets
36 consistent gets
9 physical reads
124 redo size
421 bytes sent via SQL*Net to client
420 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
1 rows processed
14:36:35 HR 6805>@check
NAME TYPE SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ ------------ ------------- ------------ ---------------- HR.TEST_RC Dependency 0 76779 1 SELECT /*+ result_cache */ max Result 0 0 0 (empno) FROM test_rc
select /*+ result_cache */ cou Result 2 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 5 0 5 0 0
|
기존에 Dependency 가 존재 하더라도 두 번의 RC enqueue 요청이 발생 하였다. Dependency의 invalidation 상태를 체크 한 후에 쿼리 Result를 등록 시도 하는 것으로 추정이 된다. 아직 Oracle 11g 관련 문서의 부재로 테스트에 의존 할 수 밖에 없는 상황이라서 확실히 결론을 내리기는 어렵다.
- Test Case#4
RC Enqueue 경합을 발생 시켜서 v$enqueue_stat 뷰 및 세션 10046 Trace이용하여 wait Event를 확인 해 보도록 하자.
서로 다른 세션에서 dml.sql을 수행하게 한 후 10046 Trace 확인
|
- dml.sql
declare
v_cnt number ;
begin
for i IN 1..100000 LOOP
insert into test_rc values ( 105 , 'N 105' ) ;
commit ;
select /*+ result_cache */ count(*) into v_cnt from test_rc ;
delete test_rc where empno = 105 ;
commit ;
end loop;
end;
/
|
|
- Session #1
14:43:26 HR 7940>alter session set events '10046 trace name context forever ,level 12' ;
Session altered.
14:43:41 HR 7940>@dml
|
|
- Session #2
14:44:13 HR 7969>alter session set events '10046 trace name context forever , level 12' ;
Session altered.
14:44:29 HR 7969>@dml
|
|
- DBA Session
14:46:33 SYS 8037>SELECT * FROM v$lock WHERE type = 'RC';
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- ---------- -------32367818 32367844 170 RC 1 31 6 0 0 0
14:46:35 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 138 RC 2 76779 4 0 0 0
14:48:08 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 138 RC 1 31 6 0 0 0
14:48:27 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 170 RC 1 30 6 0 0 0
3236788C 323678B8 138 RC 1 31 6 0 0 0
14:52:52 SYS 8037>SELECT * FROM v$lock WHERE type = 'RC';
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 138 RC 2 76779 3 0 0 0
14:53:59 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 138 RC 2 76779 4 0 0 0
3236788C 323678B8 170 RC 1 30 4 0 0 0
14:54:33 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 138 RC 2 76779 4 0 0 0
3236788C 323678B8 170 RC 1 31 4 0 0 0
14:55:17 SYS 8037>/
ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- --------- -------32367818 32367844 170 RC 1 31 6 0 0 1
3236788C 323678B8 138 RC 1 31 0 4 0 0
|
위와 같이 v$lock 뷰를 조회해 보면 Object id 가 76779(TEST_RC-TABLE) , 30(I_COBJ#-INDEX) , 31(CDEF$-TABLE)에 대한 요청이 발생하고 있다. 이 시점에 v$result_cache_objects뷰를 조회해 보면 동일 SELECT /*+ result_cache */ COUNT(*) FROM TEST_RC 쿼리가 여러 개 등록 됨을 확인 할 수 있다. 즉 하나 하나 새로운 쿼리 Result를 등록하고 사용하고 등록하고 사용하고 하는 것이다.
|
15:21:20 SYS 8606>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.TEST_RC Dependency Published 0 76779 2298194
SELECT /*+ result_cache */ COU Result Published 0 0 0
NT(*) FROM TEST_RC
select /*+ result_cache */ cou Result Invalid 2 0 0
nt(*) from test_rc
SELECT /*+ result_cache */ max Result Invalid 0 0 0
(empno) FROM test_rc
SELECT /*+ result_cache */ COU Result Invalid 0 0 0
NT(*) FROM TEST_RC
.....같은 데이터 생략
32 rows selected.
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 10235843 229662 10054184 181655 27890
15:21:45 SYS 8606>set serveroutput on
15:23:33 SYS 8606>exec dbms_result_cache.memory_report(true) ;
R e s u l t C a c h e M e m o r y R e p o r t
[Parameters]
Block Size = 1K bytes
Maximum Cache Size = 3296K bytes (3296 blocks)
Maximum Result Size = 164K bytes (164 blocks)
[Memory]
Total Memory = 103528 bytes [0.112% of the Shared Pool]
... Fixed Memory = 5132 bytes [0.006% of the Shared Pool]
....... Cache Mgr = 108 bytes
....... Memory Mgr = 124 bytes
....... Bloom Fltr = 2K bytes
....... State Objs = 2852 bytes
... Dynamic Memory = 98396 bytes [0.107% of the Shared Pool]
....... Overhead = 65628 bytes
........... Hash Table = 32K bytes (4K buckets)
........... Chunk Ptrs = 12K bytes (3K slots)
........... Chunk Maps = 12K bytes
........... Miscellaneous = 8284 bytes
....... Cache Memory = 32K bytes (32 blocks)
........... Unused Memory = 0 blocks
........... Used Memory = 32 blocks
............... Dependencies = 1 blocks (1 count)
............... Results = 31 blocks
................... SQL = 1 blocks (1 count)
................... Invalid = 30 blocks (30 count)
PL/SQL procedure successfully completed.
15:23:45 SYS 8606>show parameter result_cache_max_size
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
result_cache_max_size big integer 3296K
15:25:09 SYS 8606>SELECT name , GETS ,MISSES ,SPIN_GETS FROM v$latch WHERE name like '%Result%' ;
NAME GETS MISSES SPIN_GETS
------------------------------ ---------- ---------- ----------
Result Cache: Latch 28045823 131600 108373
Result Cache: SO Latch 4 0 0
|
Cache Memory에서 1K사이즈 블록을 32개 사용 중이며, 그 중 1개는 Dependency 정보이고 나머지 31개가 SQL Result 이다. 그 중 현재 사용되는 SQL result가 1개 이고 나머지는 invalid 상태임을 확인 할 수 있다.
이 부분은 전혀 예상하지 못했던 부분이다. 단지 RC enqueue 요청 횟수와 v$lock에서의 정보를 확인 해 보기 위한 테스트 였는데 전혀 뜻밖에 동일 SQL이 invalid 되면서 새로운 데이터가 캐시 되고 사용되고 하는 것을 확인 할 수 있다. 이는 latch 요청 증가를 확인해도 알 수 있다.
- Test Case#5
그럼 왜 ? 동일 SQL을 수행하는데 각각의 쿼리들이 새로 등록이 되고 사용이 되는 것일까 ? 어느 경우 이런 경우가 발생 하는지 확인 해 보도록 하자.
|
16:04:30 HR 11983>@check
no rows selected
no rows selected
16:04:47 HR 11983>set autotrace on exp stat
16:05:23 HR 11983>select /*+ result_cache */ count(*) from test_rc ;
COUNT(*)
----------
106
Execution Plan
----------------------------------------------------------
Plan hash value: 1775316367
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
| 1 | RESULT CACHE | 3dhb1js3x6ghf0zdkxtn6cwvsp | | | |
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| TEST_RC | 106 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
75 recursive calls
0 db block gets
14 consistent gets
0 physical reads
0 redo size
419 bytes sent via SQL*Net to client
420 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1 rows processed
16:05:32 HR 11983>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.TEST_RC Dependency Published 0 76779 0
select /*+ result_cache */ cou Result Published 1 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 2 0 2 0 0
|
정상적으로 하나의 Result 데이터를 로드 하였다. DML을 발생 후 어떠한 변화가 있는지 확인해 보자
|
16:05:35 HR 11983> insert into test_rc values ( 1000 , 'N1000') ;
1 row created.
16:08:41 HR 11983>commit ;
Commit complete.
16:08:44 HR 11983>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.TEST_RC Dependency Published 0 76779 1
select /*+ result_cache */ cou Result Invalid 1 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 3 0 3 0 0
|
DML발생 후에도 Result Cache에 데이터는 늘어 나지 않았다. 이 시점에 동일 SQL문을 재 수행 해 보도록 하겠다.
|
16:09:16 HR 11983>select /*+ result_cache */ count(*) from test_rc ;
COUNT(*)
----------
107
Execution Plan
----------------------------------------------------------
Plan hash value: 1775316367
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
| 1 | RESULT CACHE | 3dhb1js3x6ghf0zdkxtn6cwvsp | | | |
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| TEST_RC | 107 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
1229 recursive calls
10 db block gets
213 consistent gets
13 physical reads
124 redo size
419 bytes sent via SQL*Net to client
420 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
17 sorts (memory)
0 sorts (disk)
1 rows processed
16:10:30 HR 11983>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.TEST_RC Dependency Published 0 76779 1
select /*+ result_cache */ cou Result Published 0 0 0
nt(*) from test_rc
select /*+ result_cache */ cou Result Invalid 1 0 0
nt(*) from test_rc
Elapsed: 00:00:00.03
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 5 0 5 0 0
16:18:03 SYS >set serveroutput on
16:18:07 SYS >exec dbms_result_cache.memory_report(true);
R e s u l t C a c h e M e m o r y R e p o r t
[Parameters]
Block Size = 1K bytes
Maximum Cache Size = 3296K bytes (3296 blocks)
Maximum Result Size = 164K bytes (164 blocks)
[Memory]
Total Memory = 103528 bytes [0.099% of the Shared Pool]
... Fixed Memory = 5132 bytes [0.005% of the Shared Pool]
....... Cache Mgr = 108 bytes
....... Memory Mgr = 124 bytes
....... Bloom Fltr = 2K bytes
....... State Objs = 2852 bytes
... Dynamic Memory = 98396 bytes [0.094% of the Shared Pool]
....... Overhead = 65628 bytes
........... Hash Table = 32K bytes (4K buckets)
........... Chunk Ptrs = 12K bytes (3K slots)
........... Chunk Maps = 12K bytes
........... Miscellaneous = 8284 bytes
....... Cache Memory = 32K bytes (32 blocks)
.......... Unused Memory = 29 blocks
........... Used Memory = 3 blocks
............... Dependencies = 1 blocks (1 count)
............... Results = 2 blocks
................... SQL = 1 blocks (1 count)
................... Invalid = 1 blocks (1 count)
PL/SQL procedure successfully completed.
|
위와 같이 참조 Object가 invalid 된 후 재 수행된 SQL문은 cache id 는 같지만 새로운 메모리 영역을 사용함을 확인 할 수 있다. 마치 동일 SQL이지만 실행 계획이 여러 개 생성 될 경우 Child LCO가 늘어 나는 거 같은 느낌이다. 혹시 library cache 영역과 관계가 있을까 해서 v$sqlarea , v$sql 쿼리를 수행해 보지만 select /*+ result_cache */ count(*) from test_rc 라는 SQL문은 찾아 볼 수 없다. 기존에 SQL 수행 단계에서 library cache영역을 확인하기 전에 Result Cache 영역을 조사하는 로직이 하나 추가된 것으로 추정이 된다. library cache 영역과 별개로 Result Cache영역이 사용되고 있음을 확인 할 수있다.
그럼 SQL Result만 새로 추가 되는 것인지 , 아니면 펑션을 사용하는 Result도 재 등록 되는지 확인해 보도록 하자.
|
create or replace function f_test_rc return number result_cache
as
v_cnt number ;
begin
select count(*) into v_cnt from test_rc ;
return v_cnt ;
end ;
|
|
16:27:10 HR 11983>SELECT f_test_rc FROM dual ;
F_TEST_RC
----------
107
16:27:27 HR 11983>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.F_TEST_RC Dependency Published 0 76788 0
HR.TEST_RC Dependency Published 0 76779 1
"HR"."F_TEST_RC"::8."F_TEST_RC Result Published 0 0 0
"#9689ba467a19cd19 #1
select /*+ result_cache */ cou Result Published 0 0 0
nt(*) from test_rc
select /*+ result_cache */ cou Result Invalid 1 0 0
nt(*) from test_rc
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 7 0 7 0 0
16:28:24 HR 11983>alter function f_test_rc compile ;
Function altered.
Elapsed: 00:00:00.12
16:29:46 HR 11983>SELECT f_test_rc FROM dual ;
F_TEST_RC
----------
108
16:29:57 HR 11983>@check
NAME TYPE STATUS SCAN_COUNT OBJECT_NO INVALIDATIONS
------------------------------ --------- --------- ---------- ---------- ------------- HR.F_TEST_RC Dependency Published 0 76788 1
HR.TEST_RC Dependency Published 0 76779 2
"HR"."F_TEST_RC"::8."F_TEST_RC Result Published 0 0 0
"#9689ba467a19cd19 #1
select /*+ result_cache */ cou Result Invalid 1 0 0
nt(*) from test_rc
select /*+ result_cache */ cou Result Invalid 0 0 0
nt(*) from test_rc
"HR"."F_TEST_RC"::8."F_TEST_RC Result Invalid 0 0 0 "#9689ba467a19cd19 #1
6 rows selected.
INST_ID EQ_T TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
------ ------ -------------- ------------- ------------ -------------- ----------------
1 RC 11 0 11 0 0
|
위와 같이 새로이 등록됨을 확인 할 수 있다. Invalidation 되는 경우가 많지 않은 경우에 Result Cache를 사용해야지 그렇지 않을 경우 다른 Result Cache 데이터 까지 age out 되어서 불 필요한 RC enqueue 및 Result Cache latch 경합이 발생할 소지가 높다.
그러면 특정 한 Result를 keep 시키는 명령어는 존재를 할 것인가 ? 아쉽게도 dbms_result_cache 패키지로는 불가능 하다.
여기까지 RC Enqueue 는 Result Cache에 대한 등록 및 변경 작업이 있을 경우 획득하는 lock임을 확인 할 수 있었고, 잦은 DML이 발생하는 테이블에 대해서는 Result Cache를 사용하지 말아야 한다는 것을 테스트를 통해 확인 할 수 있었다.
추후 특정 Result Cache 에 대해서 keep 시킬 수 있는 방법을 알게 된다면 추가 하도록 하겠다.