sql result cache for improving the performance (merged 4) [message #610629] |
Sat, 22 March 2014 03:05 |
|
kiranrathodkr916
Messages: 36 Registered: March 2014 Location: India
|
Member |
|
|
How effective sql result cache would be if we set that for entire db,How long it would take to collect and store the data in cache and how much cache would be consumed by having this turned on,how can we estimate the performance impact?can someone shed some light on this
|
|
|
Re: sql result cache for improving the performance [message #610630 is a reply to message #610629] |
Sat, 22 March 2014 03:36 |
John Watson
Messages: 8960 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Welcome to the forum. Please read our OraFAQ Forum Guide and please read How to use [code] tags and make your code easier to read
If you read the docs on the Result Cache, you will see that the size is limited by whatever value you give the RESULT_CACHE_SIZE instance parameter. As is populated by running queries, it is not possible to say how long this will take. Estimating the impact is easy, just do a few tests:
orclz>
orclz> alter session set result_cache_mode=force;
Session altered.
orclz> set timing on;
orclz> select count(*) from oe.PRODUCT_DESCRIPTIONS,oe.PRODUCT_DESCRIPTIONS;
COUNT(*)
----------
74649600
Elapsed: 00:00:02.26
orclz> select count(*) from oe.PRODUCT_DESCRIPTIONS,oe.PRODUCT_DESCRIPTIONS;
COUNT(*)
----------
74649600
Elapsed: 00:00:00.01
orclz>
|
|
|
|
|
|
|
|
|
|
|
Re: What is your experience with Oracle's result caching feature? [message #610721 is a reply to message #610720] |
Sun, 23 March 2014 10:14 |
|
BlackSwan
Messages: 26766 Registered: January 2009 Location: SoCal
|
Senior Member |
|
|
>how to interpret the memory report
It appears you DB is as small & idle as mine.
SQL> 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 = 1120K bytes (1120 blocks)
Maximum Result Size = 56K bytes (56 blocks)
[Memory]
Total Memory = 103532 bytes [0.060% of the Shared Pool]
... Fixed Memory = 5180 bytes [0.003% of the Shared Pool]
....... Memory Mgr = 128 bytes
....... Cache Mgr = 152 bytes
....... Bloom Fltr = 2K bytes
....... State Objs = 2852 bytes
... Dynamic Memory = 98352 bytes [0.057% of the Shared Pool]
....... Overhead = 65584 bytes
........... Hash Table = 32K bytes (4K buckets)
........... Chunk Ptrs = 12K bytes (3K slots)
........... Chunk Maps = 12K bytes
........... Miscellaneous = 8240 bytes
....... Cache Memory = 32K bytes (32 blocks)
........... Unused Memory = 27 blocks
........... Used Memory = 5 blocks
............... Dependencies = 1 blocks (1 count)
............... Results = 4 blocks
................... SQL = 4 blocks (4 count)
PL/SQL procedure successfully completed.
SQL>
--moderator update: added [code] tags, please do so yourself in future.
[Updated on: Sun, 23 March 2014 11:54] by Moderator Report message to a moderator
|
|
|
no improvement using result cache [message #610764 is a reply to message #610629] |
Mon, 24 March 2014 03:34 |
|
ashwanth77
Messages: 95 Registered: April 2013 Location: India
|
Member |
|
|
Usage of result cache hint for the subsequent invocation shows negligible or no improvement in time
select /*+result_cache*/ status from demand_plan2 where dp_id=309;
can someone what could be the reason.why this happening?
[EDITED by LF: fixed topic title typo; was "cahce"]
[Updated on: Mon, 24 March 2014 05:06] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
Re: why isn't my result cache not working? [message #610837 is a reply to message #610835] |
Tue, 25 March 2014 01:57 |
John Watson
Messages: 8960 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
In your previous topic, you posted information showing that the result cache was working, but you said that it wasn't. In this topic, you have posted some parameter values but nothing else: no query, no exec plan, no figures for execution time or I/O.
Very difficult to assist in such circumstances.
As for your query, it works for me:
london> SELECT DBMS_RESULT_CACHE.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
-------------------------------------------------------
ENABLED
london>
|
|
|
Re: why isn't my result cache not working? [message #610847 is a reply to message #610837] |
Tue, 25 March 2014 02:52 |
|
ashwanth77
Messages: 95 Registered: April 2013 Location: India
|
Member |
|
|
Execution plan :
without /*+ result_cahe */ hint
SQL> SELECT FCST.Lev_RP_GBURECON_TYPE.Member_Key, FCST.Lev_RP_GBURECON_TYPE.Member_ID, FCST.Lev_RP_GBURECON_TYPE.Member_
Name, FCST.Lev_RP_GBURECON_TYPE.Member_Description, FCST.Lev_RP_GBURECON_TYPE.Sequence FROM FCST.Hry_RP_GBURECON_TYPE_SE
LECT,FCST.Lev_RP_GBURECON_TYPE WHERE FCST.Lev_RP_GBURECON_TYPE.Member_Key=FCST.Hry_RP_GBURECON_TYPE_SELECT.Member_Key AN
D FCST.Hry_RP_GBURECON_TYPE_SELECT.Level_Key=1312010 ORDER BY FCST.Lev_RP_GBURECON_TYPE.Member_ID;
Elapsed: 00:00:02.11
Execution Plan
----------------------------------------------------------
Plan hash value: 1484964662
--------------------------------------------------------------------------------
-------------------
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
--------------------------------------------------------------------------------
-------------------
| 0 | SELECT STATEMENT | | 4 | 288 |
8 (25)| 00:00:01 |
| 1 | SORT ORDER BY | | 4 | 288 |
8 (25)| 00:00:01 |
|* 2 | HASH JOIN | | 4 | 288 |
7 (15)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| HRY_RP_GBURECON_TYPE_SELECT | 4 | 48 |
3 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL| LEV_RP_GBURECON_TYPE | 4 | 240 |
3 (0)| 00:00:01 |
--------------------------------------------------------------------------------
-------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("LEV_RP_GBURECON_TYPE"."MEMBER_KEY"="HRY_RP_GBURECON_TYPE_SELECT".
"MEMBER_KEY
")
3 - filter("HRY_RP_GBURECON_TYPE_SELECT"."LEVEL_KEY"=1312010)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
629 bytes sent via SQL*Net to client
248 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
4 rows processed
with /*+ result_cahe */ hint
SQL> SELECT /*+ result_cache */ FCST.Lev_RP_GBURECON_TYPE.Member_Key, FCST.Lev_RP_GBURECON_TYPE.Member_ID, FCST.Lev_RP_G
BURECON_TYPE.Member_Name, FCST.Lev_RP_GBURECON_TYPE.Member_Description, FCST.Lev_RP_GBURECON_TYPE.Sequence FROM FCST.Hry
_RP_GBURECON_TYPE_SELECT,FCST.Lev_RP_GBURECON_TYPE WHERE FCST.Lev_RP_GBURECON_TYPE.Member_Key=FCST.Hry_RP_GBURECON_TYPE_
SELECT.Member_Key AND FCST.Hry_RP_GBURECON_TYPE_SELECT.Level_Key=1312010 ORDER BY FCST.Lev_RP_GBURECON_TYPE.Member_ID;
Elapsed: 00:00:02.16
Execution Plan
----------------------------------------------------------
Plan hash value: 1484964662
--------------------------------------------------------------------------------
--------------------
| Id | Operation | Name | Rows | Bytes | Cos
t (%CPU)| Time |
--------------------------------------------------------------------------------
--------------------
| 0 | SELECT STATEMENT | | 4 | 288 |
8 (25)| 00:00:01 |
| 1 | RESULT CACHE | 5auhmbpa5j4x789bfdp5mu3m3u | | |
| |
| 2 | SORT ORDER BY | | 4 | 288 |
8 (25)| 00:00:01 |
|* 3 | HASH JOIN | | 4 | 288 |
7 (15)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| HRY_RP_GBURECON_TYPE_SELECT | 4 | 48 |
3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| LEV_RP_GBURECON_TYPE | 4 | 240 |
3 (0)| 00:00:01 |
--------------------------------------------------------------------------------
--------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("LEV_RP_GBURECON_TYPE"."MEMBER_KEY"="HRY_RP_GBURECON_TYPE_SELECT".
"MEMBER_KEY"
)
4 - filter("HRY_RP_GBURECON_TYPE_SELECT"."LEVEL_KEY"=1312010)
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=5; dependencies=(FCST.LEV_RP_GBURECON_TYPE, FCST.HRY_RP_GBUR
ECON_TYPE_SELECT); parameters=(nls); name="SELECT /*+ result_cache */ FCST.Lev_R
P_GBURECON_TYPE.Member_Key, FCST.Lev_RP_GBURECON_TYPE.Member_ID, FCST.Lev_RP_GBU
RECON_TYPE."
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
630 bytes sent via SQL*Net to client
248 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
4 rows processed
again with /*+ result_cahe */ hint
SQL> SELECT /*+ result_cache */ FCST.Lev_RP_GBURECON_TYPE.Member_Key, FCST.Lev_RP_GBURECON_TYPE.Member_ID, FCST.Lev_RP_
BURECON_TYPE.Member_Name, FCST.Lev_RP_GBURECON_TYPE.Member_Description, FCST.Lev_RP_GBURECON_TYPE.Sequence FROM FCST.Hr
_RP_GBURECON_TYPE_SELECT,FCST.Lev_RP_GBURECON_TYPE WHERE FCST.Lev_RP_GBURECON_TYPE.Member_Key=FCST.Hry_RP_GBURECON_TYPE
SELECT.Member_Key AND FCST.Hry_RP_GBURECON_TYPE_SELECT.Level_Key=1312010 ORDER BY FCST.Lev_RP_GBURECON_TYPE.Member_ID;
Elapsed: 00:00:02.16
Execution Plan
----------------------------------------------------------
Plan hash value: 1484964662
--------------------------------------------------------------------------------
--------------------
| Id | Operation | Name | Rows | Bytes | Cos
t (%CPU)| Time |
--------------------------------------------------------------------------------
--------------------
| 0 | SELECT STATEMENT | | 4 | 288 |
8 (25)| 00:00:01 |
| 1 | RESULT CACHE | 5auhmbpa5j4x789bfdp5mu3m3u | | |
| |
| 2 | SORT ORDER BY | | 4 | 288 |
8 (25)| 00:00:01 |
|* 3 | HASH JOIN | | 4 | 288 |
7 (15)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| HRY_RP_GBURECON_TYPE_SELECT | 4 | 48 |
3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| LEV_RP_GBURECON_TYPE | 4 | 240 |
3 (0)| 00:00:01 |
--------------------------------------------------------------------------------
--------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("LEV_RP_GBURECON_TYPE"."MEMBER_KEY"="HRY_RP_GBURECON_TYPE_SELECT".
"MEMBER_KEY"
)
4 - filter("HRY_RP_GBURECON_TYPE_SELECT"."LEVEL_KEY"=1312010)
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=5; dependencies=(FCST.LEV_RP_GBURECON_TYPE, FCST.HRY_RP_GBUR
ECON_TYPE_SELECT); parameters=(nls); name="SELECT /*+ result_cache */ FCST.Lev_R
P_GBURECON_TYPE.Member_Key, FCST.Lev_RP_GBURECON_TYPE.Member_ID, FCST.Lev_RP_GBU
RECON_TYPE."
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
630 bytes sent via SQL*Net to client
248 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
my question is why there is no drop in time during subsequent execution.the time is supposed to drop.
|
|
|
|
|