Result_cache

Hi to all!
I would like to ask about issue of result_cache setting. The doc describing result_cache setting: result_cache_mode is set to 'MANUAL' and parameter result_cache_max_size is set to 0 means the cache is disabled (correct). If we set by issuing ALTER SYSTEM statement to set RESULT_CACHE_MAX_SIZE to a nonzero value but do not restart the database, querying the value of the RESULT_CACHE_MAX_SIZE parameter returns a nonzero value even though the result cache is still disabled(this is on doubt?). The value of RESULT_CACHE_MAX_SIZE is therefore not the most reliable way to determine if the result cache is enabled. You can use the following query instead:
SELECT dbms_result_cache.status() FROM dual;
But if I simulated this on database 11g, after setting cache size to nonzero value I have got always from querying status 'ENABLE'. Then cache is enabled not like saying orig doc of 11g. Should someone comment it,if there is something else behind?
Thanks, JoKo

Hi Sven,
I forgot to mention, I made it in SCOPE=BOTH, then persistent. But I have been showing real text from 11g's doc. And more, I have got test for 11g Advanced PL/SQL and there is the same fault telling me result cache is disabled in case when mode 'MANUAL' and size set recently to > 0 if db not restarted. Anyway, thanks a lot, JoKo.

Similar Messages

What's wrong with the following result_cache hint?

Dear all,
I try to use result_cache hint in the following sql aggregate function statement, but the explain plan doesn't show any difference between non-result_cached and with result_cached:
SQL> set autot on explain stat
SQL> select account_mgr_id,count(*) from customers group by account_mgr_id;
ACCOUNT_MGR_ID      COUNT(*)
        147            76
        149            74
        148            58
        145           111
Execution Plan
Plan hash value: 1577413243
| Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |            |     4 |    16 |     6     (17)| 00:00:01 |
|   1 | HASH GROUP BY        |            |     4 |    16 |     6     (17)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| CUSTOMERS |   319 | 1276 |     5      (0)| 00:00:01 |
Statistics
       0 recursive calls
       0 db block gets
      16 consistent gets
       0 physical reads
       0 redo size
     689 bytes sent via SQL*Net to client
     524 bytes received via SQL*Net from client
       2 SQL*Net roundtrips to/from client
       0 sorts (memory)
       0 sorts (disk)
       4 rows processed
SQL> select /*+ result_cache */ account_mgr_id,count(*) from customers group by account_mgr_id;
ACCOUNT_MGR_ID      COUNT(*)
        147            76
        149            74
        148            58
        145           111
Execution Plan
Plan hash value: 1577413243
| Id | Operation         | Name                | Rows | Bytes | Cost (%CPU)| Time      |
|   0 | SELECT STATEMENT    |                     |     4 |    16 |     6 (17)| 00:00:01 |
|   1 | RESULT CACHE         | 3s3bugtq0p5bm71mhmqvvw0x7y |      |      |           |       |
|   2 |   HASH GROUP BY     |                     |     4 |    16 |     6 (17)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| CUSTOMERS            |   319 | 1276 |     5   (0)| 00:00:01 |
Result Cache Information (identified by operation id):
   1 - column-count=2; dependencies=(OE.CUSTOMERS); name="select /*+ result_cache */ account_mgr_id,
count(*) from customers group by account_mgr_id"
Statistics
       1 recursive calls
       0 db block gets
      16 consistent gets
       0 physical reads
       0 redo size
     689 bytes sent via SQL*Net to client
     524 bytes received via SQL*Net from client
       2 SQL*Net roundtrips to/from client
       0 sorts (memory)
       0 sorts (disk)
       4 rows processedAnything wrong with the hint?
Best regards,
Val

Two executions required to benefit from result cache (two executions of the statement with the result cache hint).
First to populate, Second to benefit.
Can offer good benefits particularly with poor code - e.g. functions in SQL, row-by-row function calls, etc.
Optimal solution may be to refactor to more efficient approach.
But result cache can deliver significant short term tactical gain.
Not a no-brainer though.
There were scalability issues with a single latch protecting the result cache - I believe this has changed in 11gR2.
There are also issues with concurrent executions were the result needs to be recalculated and takes x time to regenerate that result.
See http://uhesse.wordpress.com/2009/11/27/result-cache-another-brilliant-11g-new-feature/#comment-216
SQL> drop table t1;
Table dropped.
SQL>
SQL> create table t1
2 as
3 select rownum col1
4 from   dual
5 connect by rownum <= 100000;
Table created.
SQL> set autotrace traceonly explain statistics
SQL> select col1
2 from   t1
3 where col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    10 |   130 |    58   (9)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1">=99997)
Note
   - dynamic sampling used for this statement (level=4)
Statistics
         10 recursive calls
          0 db block gets
        220 consistent gets
        153 physical reads
          0 redo size
        379 bytes sent via SQL*Net to client
        334 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL> select col1
2 from   t1
3 where col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    10 |   130 |    58   (9)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1">=99997)
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          0 recursive calls
          0 db block gets
        158 consistent gets
          0 physical reads
          0 redo size
        379 bytes sent via SQL*Net to client
        334 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL>
SQL>
SQL> select /*+ result_cache */ col1
2 from   t1
3 where col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id | Operation          | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
|   1 | RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("COL1">=99997)
Result Cache Information (identified by operation id):
   1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
from   t1
where col1 >= 99997"
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          4 recursive calls
          0 db block gets
        216 consistent gets
          0 physical reads
          0 redo size
        379 bytes sent via SQL*Net to client
        334 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL>
SQL>
SQL> select /*+ result_cache */ col1
2 from   t1
3 where col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id | Operation          | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
|   1 | RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("COL1">=99997)
Result Cache Information (identified by operation id):
   1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
from   t1
where col1 >= 99997"
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        379 bytes sent via SQL*Net to client
        334 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL>

Is result_cache working in Oracle 11.1.0.6.0?

BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Solaris: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL> SELECT dbms_result_cache.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
--------------------------------------------------------------------------------------------------------------------------------------------------------------------ENABLED
12:31:08 SQL> set autotrace on
select count(*) from objs;
12:31:27 SQL>
COUNT(*)
69918
Elapsed: 00:00:01.72
Execution Plan
Plan hash value: 386529197
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 289 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| OBJS | 80773 | 289 (1)| 00:00:04 |
Note
- dynamic sampling used for this statement
Statistics
282 recursive calls
0 db block gets
1140 consistent gets
1038 physical reads
0 redo size
524 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
12:31:49 SQL> select /*+ result_cache */ count(*) from objs;
COUNT(*)
69918
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 386529197
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 289 (1)| 00:00:04 |
| 1 | RESULT CACHE | cnsc9rw3p17364cbg4975pad6y | | | |
| 2 | SORT AGGREGATE | | 1 | | |
| 3 | TABLE ACCESS FULL| OBJS | 80773 | 289 (1)| 00:00:04 |
Result Cache Information (identified by operation id):
1 - column-count=1; dependencies=(CTSGKOD.OBJS); attributes=(single-row); name="select /*+ result_cache */ count(*) from objs"
Note
- dynamic sampling used for this statement
Statistics
4 recursive calls
0 db block gets
1110 consistent gets
0 physical reads
0 redo size
524 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
12:32:06 SQL>
i see result_cache in execution plan, but why do i see 1110 consistent gets? I expected 0 in consisent gets and physical reads and the query is not executed ...
Thank You

Aman,
lets say i run these statements
1) exec dbms_result_cache.flush
2) alter system flush shared_pool;
3)alter system flush buffer_cache;
Then i run the query without hint of result_cache
4) Select count(*) from objs; --> This query is not using result cache, it is running for first time, so physical reads & consistent gets
5) select count(*) from objs; --> again same query, this time only consistent gets
6) select /*+ result_cache */ count(*) from objs; -- Lets introduce result_cache now
Will the above query gets data from buffer cache or will it use result_cache and gets result from memory instead of running query? Or will this 6th statement run same as (5) and prepares ground for usage of result_cache and
any other queries later can benefit from result_cache?
Thanks again Aman

PL/Sql RESULT_CACHE Function under VPD environment

Hi,
Imagine that I have a VPD environment that depending on the user the data returned from the table in a schema is different than returned to other user. for instance:
The VPD filters the data by company_id in this table
table persons
company_id number(4),
person_id number(4)
person varchar2(100)
now imagine that I connect as scott and scott belongs company_id 1000. If scott runs select * from schema.persons he will see this
1000 123 ANNA
1000 124 MARY
1000 125 SCOTT
If I connect as JOHN and JOHN belongs to company_id 1111. If scott runs select * from schema.persons he will see this
1111 123 ALBERT
1111 124 KEVIN
1111 125 JOHN
This is the VPD environment I have...
So, does RESULT_CACHE functions works well under this type of environment? RESULT_CACHE is shared between sessions... but in this case the sessions of scott and john see always different results. Is there any option of implementing RESULT_CACHE by username?
Regards
Ricardo

It appears that the result cache functionality can work with Virtual Private Database. Check out the following links:
Adventures with VPD I: Result Cache
Concepts: Result Cache

RESULT_CACHE hint

I am trying to figure out why the explain plan (and performance) for the same query is different between our staging environment and our production environment when using the RESULT_CACHE hint. It's significantly worse in production. Platform and database version is the same. There are differences in the init settings between the two environments, specifically the following:
In Stage:
optimizer_mode = first_rows_100
result_cache_mode=manual
result_cache_max_result=5
result_cache_max_size=7872K
cursor_sharing=similar
In Prod:
optimizer_mode =
result_cache_mode=
result_cache_max_result=
result_cache_max_size=
cursor_sharing=exact
When I run the query in Stage, the explain plan looks like this:
Execution Plan
Plan hash value: 3058471186
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 263 | 8 (13)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 263 | 8 (13)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 1 | 195 | 4 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | HOLDING_CALC2_IDX | 1 | | 3 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 1 | 68 | 3 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | HOLDING_CALC_IDX | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("STATEMENT_DATE"=MAX("STATEMENT_DATE"))
4 - filter(UPPER("SYMBOL")=UPPER(NVL(NULL,"SYMBOL")) AND "SECURITY_TYPE"<>'NO REVIEW
REQUIRED' AND ("STATEMENT_DATE">=INTERNAL_FUNCTION("STATEMENT_DATE")-.0000115740740740740740
7407407407407407407407 OR "STATEMENT_DATE"=NULL) AND "ACTIVE_FLAG"='Y' AND
"STATEMENT_DATE"<=SYSDATE@!-3)
5 - access("BROKERAGE_ACCOUNT_ID"=14873 AND "USER_ID"=39356 AND "CLIENT_ID"=609)
6 - filter("B"."ACTIVE_FLAG"='Y' AND "B"."STATEMENT_DATE"<=SYSDATE@!-3 AND
"A"."SYMBOL"="B"."SYMBOL")
7 - access("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609 AND "A"."SECURITY_TYPE"="B"."SECURITY_TYPE")
filter("B"."SECURITY_TYPE"<>'NO REVIEW REQUIRED')
Statistics
0 recursive calls
0 db block gets
1356 consistent gets
0 physical reads
0 redo size
1904 bytes sent via SQL*Net to client
360 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
When I run it in Prod:
Execution Plan
Plan hash value: 1021161140
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 252 | 239 (1)| 00:00:03 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 1 | 252 | 239 (1)| 00:00:03 |
| 3 | VIEW | VW_SQ_1 | 1 | 88 | 236 (1)| 00:00:03 |
|* 4 | FILTER | | | | | |
| 5 | HASH GROUP BY | | 1 | 83 | 236 (1)| 00:00:03 |
|* 6 | TABLE ACCESS BY INDEX ROWID| C11_HOLDINGS | 256 | 21248 | 235 (0)| 00:00:03 |
|* 7 | INDEX RANGE SCAN | HOLDING_CALC2_IDX | 512 | | 5 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | HOLDINGS_SYMB_IDX | 1 | | 2 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | C11_HOLDINGS | 1 | 164 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609 AND MAX("STATEMENT_DATE")<=SYSDATE@!-3)
6 - filter("B"."ACTIVE_FLAG"='Y' AND "B"."STATEMENT_DATE"<=SYSDATE@!-3 AND
"B"."SECURITY_TYPE"<>'NO REVIEW REQUIRED')
7 - access("B"."BROKERAGE_ACCOUNT_ID"=14873 AND "B"."USER_ID"=39356 AND
"B"."CLIENT_ID"=609)
8 - access("A"."SYMBOL"="ITEM_5")
filter(UPPER("SYMBOL")=UPPER(NVL(NULL,"SYMBOL")))
9 - filter("BROKERAGE_ACCOUNT_ID"=14873 AND "USER_ID"=39356 AND "CLIENT_ID"=609 AND
"ACTIVE_FLAG"='Y' AND "SECURITY_TYPE"<>'NO REVIEW REQUIRED' AND
("STATEMENT_DATE">=INTERNAL_FUNCTION("STATEMENT_DATE")-.00001157407407407407407407407407407407
407407 OR "STATEMENT_DATE"=NULL) AND "STATEMENT_DATE"<=SYSDATE@!-3 AND
"STATEMENT_DATE"="MAX(STATEMENT_DATE)" AND "A"."SECURITY_TYPE"="ITEM_4")
Statistics
0 recursive calls
0 db block gets
18051 consistent gets
0 physical reads
0 redo size
1872 bytes sent via SQL*Net to client
360 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
The queries and the data in both environments are identical. Any ideas, suggestions would be appreciated.
Thanks

Interestingly, the explain plans are identical to what they were with the result_cache hint.

Reg: result_cache in parallel -

Hi Experts,
I have few concern(s) regarding the Result Cache (introduced in 11gR2) and the /*+ RESULT_CACHE */ hint.
Refering to -
Doc 12.1 - Tuning the Result Cache
Murali Vallath - Using Oracle Database 11g Release 2 Result Cache in an Oracle RAC Environment
Adrian Billington -- query result cache in oracle 11g
Concerns -
(1) Suppose I have a master ETL job which has 5 sub-jobs. These sub-jobs are executed in parallel i.e. started all at once from ETL.
Each of these sub-job executes an extraction query and pulls data from database.
In each of these sub-job queries, there's a subquery which is common. I am thinking to provide /*+ RESULT_CACHE */ to this common subquery.
But my actual concern - since all the extraction queries (i.e. sub-jobs) are started in parallel, will the Result Cache thing come into picture?
(2) For how long the data is retained in the cache?
A wild guess - till the point we execute the DBMS_RESULT_CACHE.FLUSH procedure ?
(3) Any caveats?
(Trying to fix few costly time-consuming queries, and suddenly this option came to my mind. Took the opportunity to look at this cool feature, at the same time understanding the caveats, if any)
Please advise me on this.
-- Ranit
(on Oracle 11.2.0.3.0)

Hi.
2.1) 50Mb can store approximately 50Mb of data. The amount of stuff you can sore depends a number of factors, including:
- How many queries or function calls are being cached.
- With respect to the query cache, how wide are the rows. We are talking size of data in the columns.
- How many rows are being returned.
So you might have a few larger result sets, or many small ones.
2.2) Well, it can't. The RESULT_CACHE_MAX_RESULT parameter determines the maximum size of a result set that will be considered for caching. By default it is set to 5, which means 5% of the size. So let's say you have a result cache of 100Mb. By default, a result set in excess of 5Mb will not be considered for caching. This stops you wiping out useful information in the cache by trying to cache one big result set.
The reality is, if you start to use this feature you will have to monitor the cache performance and be selective about what you cache and what you don't. The default sizing parameters are not going to be suitable for everyone. You need to alter them based on your monitoring. Nobody in a forum will be able to tell you figures to set. If it were that easy, Oracle would do it for you.
Regarding your "alternative solution", I don't really want to comment on that specifically because I don't know enough about the system. Typically, it would not be something I would do, but maybe it is the right thing for you to do in your case. Impossible for me to know. Things to consider in preference to your alternative solution.
- Scalar subquery caching: If the subqueries are scalar subqueries (pulling back a single column/object in a single row), it will already be taking advantage of scalar subquery caching, so your alternative solutions may actually give worse performance. There is no sharing between SQL statements or sessions.
ORACLE-BASE - Efficient Function Calls From SQL
- Use a WITH clause to replace the subqueries and use the materialize hint. This way, the subquery is automatically materialized into temp segments, so multiple references to it within a single statement query the result from the temp segments, rather than the full subquery. There is no sharing between SQL statements or sessions.
ORACLE-BASE - WITH Clause : Subquery Factoring
The reality is, there is not going to be a "best" solution that works for all cases. What you need to do is try several approaches and pick the one that works best for your circumstances. The next time you run into a similar issue, you can't assume what you did last time is the right solution this time...
Regardless of which option you pick, you need to read the docs and feel comfortable with the tech before you launch down the path. No matter how good a feature is, if you use it badly you will make that feature look bad.
Cheers
Tim...

Apex using result_cache has an invalid status for wwv_flow_language query

In the v_$result_cache_objects view of SYS I noticed that Apex is using the result_cache feature of 11g.
Some of the Apex queries will have the status 'PUBLISHED', but others have the status 'INVALID'
Why does the "SELECT /*+ result_cache */ NLS_LANGUAGE, NLS_TERRITORY, NLS_SORT, NLS_WINDOWS_CHARSET FROM WWV_FLOW_LANGUAGES WHERE LANG_ID_UPPE..." query has a INVALID status?
It already happens when I start APEX (http://localhost:7778/pls/apex).
As I understand the result_cache method it will invalidate the cache after an update is done on the depending table.
Does it make sense that those Apex queries has a result_cache hint when it will be invalidated soon after?

Hi,
just had a look at our own development box and for me this query doesn't show the status INVALID. It would also not make a lot of sense because this table is only populated during installation.
When you shutdown your database and start it up again and then access APEX with http://localhost:7778/pls/apex to see the query in invalid status?
Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

Oracle RESULT_CACHE new features 11g

Hello folks !
One question about this new func of 11g : RESULT_CACHE.
I understand it permit to keep in sga a RESULT_CACHE_MAX_SIZE quantity (bytes) of resultset retrieved from sql query.
But, what the difference with this and CURSOR_SHARING set on EXACT or FORCE ?
TIA.
nico

share the result setNope. Not correct.
As Alex says - completely different features.
Cursor sharing is all about the treatment of literals in a SQL statement and the subsequent sharing of execution plans for SQL statements where only the literals were different in the original SQL.
See summary table near top of this post:
http://optimizermagic.blogspot.com/2009/05/why-do-i-have-hundreds-of-child-cursors.html

Result_cache on tables

Hi all,
I'm just experimenting with result_cache at the table level:
SQL> select *
2    from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
5 rows selected.here's my sample setup:
create table foo (id number, txt varchar2(100)) result_cache (mode force);
create table foobar(id number, foo_id number, txt varchar2(100)) result_cache (mode force);
insert into foo values (1,'test');
insert into foo values (2,'testing');
insert into foo values (3,'tester');
insert into foo values (4,'tested');
insert into foobar values (1,1,'blah');
insert into foobar values (2,1,'blah');
insert into foobar values (3,2,'blah');
insert into foobar values (4,3,'blah');
insert into foobar values (5,4,'blah');
commit;now when I select from the individual tables it appears to result cache fine:
SQL> set autotrace trace stat
SQL> select * from foo;
4 rows selected.
Statistics
         10 recursive calls
          0 db block gets
         20 consistent gets
          0 physical reads
          0 redo size
        462 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL> /
4 rows selected.
Statistics
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        462 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          4 rows processed
SQL> select * from foobar;
5 rows selected.
Statistics
          8 recursive calls
          0 db block gets
         22 consistent gets
          0 physical reads
          0 redo size
        524 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          5 rows processed
SQL> /
5 rows selected.
Statistics
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        524 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          5 rows processedbut when I run a SQL statement that combines the two, it does not cache.
SQL> select *
2    from foo     f
3    join foobar fb on (f.id = fb.foo_id)
4    where f.id in (1,2);
3 rows selected.
Statistics
          9 recursive calls
          0 db block gets
         31 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed
SQL> /
3 rows selected.
Statistics
          0 recursive calls
          0 db block gets
         15 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        364 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processedWhat am I missing here?

Hi WhiteHat. Nice test case and easily reproducible on my 11.2.0.3 Linux VM. My first guess when I looked at your query was the ansi join. My luck with them has always been bad and the luck gets worse with new-ish features.
... yours:
select *
from foo     f
join foobar fb on (f.id = fb.foo_id)
4 where f.id in (1,2);
Statistics
          9 recursive calls
          0 db block gets
         31 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed
SQL> /
Statistics
          0 recursive calls
          0 db block gets
         15 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed
SQL> /
Statistics
          0 recursive calls
          0 db block gets
         15 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed
...mine:
select *
from foo f, foobar fb
3 where f.id = fb.foo_id;
Statistics
          9 recursive calls
          0 db block gets
         31 consistent gets
          0 physical reads
          0 redo size
        676 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          5 rows processed
SQL> /
Statistics
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        676 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          5 rows processed
select *
from foo f, foobar fb
where f.id = fb.foo_id
4 and f.id in (1,2);
Statistics
          7 recursive calls
          0 db block gets
         31 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed
SQL> /
Statistics
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        634 bytes sent via SQL*Net to client
        363 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          3 rows processed

Result_cache does not work in 11g

-bash-3.00$ uname -a
SunOS tssoldb01 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
-bash-3.00$ sqlplus / as sysdba
SQL*Plus: Release 11.1.0.6.0 - Production on Fri Feb 29 11:37:14 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter result_cache_;
NAME TYPE VALUE
client_result_cache_lag big integer 3000
client_result_cache_size big integer 100M
result_cache_max_result integer 5
result_cache_max_size big integer 3M
result_cache_mode string MANUAL
result_cache_remote_expiration integer 0
SQL> select /*+ RESULT_CACHE */ object_name from dba_objects
2 where owner='SYSTEM' and object_type='PROCEDURE' ;
OBJECT_NAME
ORA$_SYS_REP_AUTH
SQL> select count(*) from v$result_cache_objects;
COUNT(*)
0
SQL>
Try the hint /*+ result_cache */ but the result cache view returns nothing. All parameters are set. Do not know why?

Oops, not query the sys views.
Thanks Chris, just read your message while post above.
Yeah, should not use dba_objects.
Message was edited by:
user498460
Message was edited by:
user498460

When oracle invalidates result_cache results without any changes in objects

Hi all!
On our production servers we have simple function with result_cache, like this:
create or replace function f_rc(p_id number) return number result_cache
is
ret number;
begin
select t.val into ret from rc_table t where t.id=p_id;
return ret;
exception
when no_data_found then
return null;
end;
/And its results frequently invalidates without any changes in table or
function. I found only 2 cases when oracle invalidates result_cache
results without any changes in table:
1. "select for update" from this table with commit;
2. deletion of unrelated rows from parent table if there is unindexed
foreign key with "on delete cascade".
I test it on 11.2.0.1, 11.2.0.3, on solaris x64 and windows. Test
cases: http://www.xt-r.com/2012/07/when-oracle-invalidates-resultcache.html
But none of them can be the cause of our situation: we have no
unindexed fk, and even if i lock all rows with "select for update", it
still does not stop invalidating.
In what other cases this happens? Am I right that the oracle does not
track any changes, but the captures of the locks and "commits"?
Best regards,
Sayan Malakshinov
http://xt-r.com

Hmm.. Do you about our situation or about test cases with "select for update" and "fk" too?
I'm not sure that it is a bug, maybe it's an architectural approach to simplify and reduce the cpu load?
Best regards,
Sayan Malakshinov
http://xt-r.com

Result_cache and data dictionary views

Hi,
Are there any special considerations when caching the results of a function which uses data dictionary views to determine it's results?
This question has popped because I have a such a result_cached function for which the result_cache objects are not getting invalidated even when the underlying data dictionary views have changed and the function gives 'stale' values in it's output. Adding the relies_on clause has not helped either.
Here is what I am trying to do:
The function accepts table name as its input and tries to determine all the child tables using the sys.dba_constraints view. The results are returned in a pl/sql table and are cached so that the subsequent calls to this function use the result_cache.
Everything works fine for the parent/child tables which have been created before the creation of this function. All the results are correct.
The problem starts when a new child table is added to an existing parent table.
The v$result_cache_objects view shows the result of this function as 'Published' and the output of the function does not show the newly created child table.
Same is the case when an existing child table is deleted; the function continues to return it in the output as it is pulled from the result_cache.
Oracle version:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

>
Restrictions on Result-Cached Functions*
To be result-cached, a function must meet all of these criteria:
* It is not defined in a module that has invoker's rights or in an anonymous block.
* It is not a pipelined table function.
* It does not reference dictionary tables, temporary tables, sequences, or nondeterministic SQL functions.
For more information, see Oracle Database Performance Tuning Guide.
* It has no OUT or IN OUT parameters.
* No IN parameter has one of these types:
o BLOB
o CLOB
o NCLOB
o REF CURSOR
o Collection
o Object
o Record
* The return type is none of these:
o BLOB
o CLOB
o NCLOB
o REF CURSOR
o Object
o Record or PL/SQL collection that contains an unsupported return type
It is recommended that a result-cached function also meet these criteria:
* It has no side effects.
For information about side effects, see "Subprogram Side Effects".
* It does not depend on session-specific settings.
For more information, see "Making Result-Cached Functions Handle Session-Specific Settings".
* It does not depend on session-specific application contexts.
>
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e17126/subprograms.htm#LNPLS698

OWB pukes on RESULT_CACHE function

I created a PL/SQL function that uses the result cache - it works well.
But when I try to import it into OWB, the tool pukes out the following error:
oracle.wh.ui.integrator.oracle.parser.ParseException: Encountered "RESULT_CACHE" at line 2, column 17OWB and database are both 11g.
Anyone had success importing result cached functions in OWB?

The import in the OWB 11g release did not support the result cache functions. You can still use/refer result cache functions in mappings just not import/deploy them, the OWB 11gR1 release was primarily the 10gR2 release with 11g certification and components seeded in the database.
Cheers
David

Hint /*+result_cache*/?

Hi guys,
11g introduce a new feature for sql query call 'result cache', I'm curious to know, does this mechanism work if i DON'T add a /*+result_cache*/ HINT to my select statement? anyone have any clues?
Many thanks.

Morven,
If result cache feature is enabled at server, then in SQL is supported by RESULT_CACHE hint only. For MANUAL result_cache_mode, the hint is a necessary practise. If u omit this in query, query will run conventionally.
Also u can test by changing the RESULT_CACHE_MODE to FORCE.

Result_cache full

Hello,
I have seen that we can manually flush the RESULT_CACHE with DBMS_RESULT_CACHE.FLUSH;
If the RESULT_CACHE is full and we don't flush it, what will it happen if we try to cache the result of a new query ?

If I understand correctly, it means that Oracle automaticly flush the result_cache for the new requests ?

Result_cache

Similar Messages

Maybe you are looking for