Result cache latch contention

Hi,
Apologies for double posting!
I had posted this query to the SQL and PL/SQL forum last week.
Result cache latch contention: http://forums.oracle.com/forums/thread.jspa?threadID=1553667&tstart=0*
Posting it here again as I am trying to better understand the RC Latch behavior before using it in our production system.
Thanks!
Edited by: kedruwsky on Oct 10, 2010 9:32 PM

sb92075 wrote:
Latches exist to manage potential contention.
What else do you not understand?
Since latches exist, they will used used regardless if you understand or not.That was profound!
Did you check the results of the 3 test cases that were executed to check how the RC Latch was used?
Results of the test cases show how many times the latch was acquired (per invocation and throughout the iterations).
I want to understand the why behind the results?
i.e. 2 latch GETS per request and acquire/release of the latch when there is a change in the request signature.
Also, result of test case 3 does not fit with the observations of test case 1 & 2.
Concurrent executions of the test cases have shown degraded performance.
Thus, I am not ready to implement this feature until I understand how it works and if there are any ways to reduce the contention.

Similar Messages

Production use of the Result Cache area

Hi all,
   OS.......: OEL 6.3 (x86_64)
   DB.......: Oracle 11.2.0.3 (x86_64)
   I would like to know from those who have used the Result Cache massively in production environments... just to know the opinion of the ones who have used this "for real". Did you use it proactively, to solve a specific problem? Or in every new database created, you configure this memory area? Did it really work as it should be?
   Thanks in advance.

Hi Fabricio,
We run result cache in our live forecast system on 11.2.0.2. We have result_cache_mode set to force and a cache of 20MB. The performance improvement we get with this is incredible, from a server running flat out to a server that looks like it's hardly doing anything. Of course it depends on exactly how your app works but we've seen no issues with it other than occassional waits for the result cache latch when there are a large number of requests - but even when this happens it's still way faster than running without result cache.
Cheers,
Harry

Latch contention in Oracle 10.2.0.4

Hello All,
There is one script which takes 8 hours to complete on one of our Oracle 10.2.0.3 databases.
The TKPROF Output shows the below Wait events:
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file scattered read                      28965        0.00          0.00
db file sequential read                   1394318        0.00          0.00
SQL*Net message to client                 4467645        0.00          0.00
SQL*Net message from client               4467645        0.00          0.00
latch: shared pool                           2847       29.05        864.44
latch: library cache                         1221        5.78        389.93
latch: row cache objects                      126        0.58          2.39
latch: cache buffers chains                  2765        0.02          0.16
log file sync                                   3        0.00          0.00
latch free                                     63        1.06          1.71
latch: object queue header operation            5        0.00          0.01
SQL*Net break/reset to client                1156        0.00          0.00
read by other session                       21609        0.99          3.99
latch: library cache lock                       1        0.01          0.01How can we reduce the "latch: shared pool" and "latch: library cache" wait/contentions?
The script in question runs 95 SELECT Statements, 3 UPDATE Statements and 1 INSERT Statement.
For more information, please let me know. Thanks.
Suddhasatwa.
Edited by: user13021719 on Mar 16, 2012 12:27 AM

Thanks for the above note.
yes the numbers are correct: there are 95 SELECT statements only in the program as well as in the TRACE file.
From the output of TKPROF I can see these 2 SELECT Statements taking maximum of these wait events:
TKPROF: Release 10.2.0.4.0 - Production on Fri Mar 16 01:25:38 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: hr84tax_ora_3391.trc
Sort options: exeela fchela prsela
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT PAYCALL2.PAY_BEGIN_DT, PAYCALL2.PAY_END_DT, PAYCALL2.CHECK_DT,
PSPCL1.COMPANY, PSPCL1.PAYGROUP, PSPCL1.PAY_END_DT, PSPCL1.PAGE_NUM,
PSPCL1.LINE_NUM, PSPCL1.OFF_CYCLE, PSPCL1.SEPCHK, PSPCL1.EMPLID,
PSPCL1.CHECK_DT, PSPCL1.PAYCHECK_OPTION, PSPCL1.PAYCHECK_STATUS
FROM
PS_PAY_CHECK PSPCL1, PS_PAY_CALENDAR PAYCALL2, PS_PAY_CAL_BAL_ID BALL1
WHERE    PAYCALL2.COMPANY     = BALL1.COMPANY AND PAYCALL2.PAYGROUP    =
BALL1.PAYGROUP AND PAYCALL2.PAY_END_DT = BALL1.PAY_END_DT AND
BALL1.BALANCE_ID     = :1 AND PAYCALL2.CHECK_DT   >= :2 AND
PAYCALL2.CHECK_DT   <= :3 AND PSPCL1.COMPANY       = :4 AND PSPCL1.EMPLID
       = :5 AND PSPCL1.COMPANY       = PAYCALL2.COMPANY AND PSPCL1.PAYGROUP
     = PAYCALL2.PAYGROUP AND PSPCL1.PAY_END_DT    = PAYCALL2.PAY_END_DT AND
PSPCL1.PAYCHECK_STATUS IN ('F','R','A') ORDER BY PAYCALL2.CHECK_DT
call     count       cpu    elapsed       disk      query    current        rows
Parse    11087      0.00       0.60          0          0          0           0
Execute 15222      0.00      17.59         11         22          0           0
Fetch    30444      0.00   16726.93     976663    8991463          0       23572
total    56753      0.00   16745.12     976674    8991485          0       23572
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 28
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
latch: shared pool                             60        1.34         10.00
latch: library cache                           22        0.34          0.86
SQL*Net message to client                   41531        0.00          0.00
SQL*Net message from client                 41531        0.00          0.00
db file sequential read                    976663        0.00          0.00
latch: cache buffers chains                     2        0.00          0.00
latch: object queue header operation            2        0.00          0.00
SELECT JB.OFFICER_CD, JB.EMPL_CLASS, JB.JOBCODE, JB.PAYGROUP,
JB.BUSINESS_UNIT, JB.STD_HOURS, JB.STD_HRS_FREQUENCY, JB.COMPRATE,
JB.EMPL_STATUS, JB.TAX_LOCATION_CD, JB.LOCATION, JB.EMPL_TYPE, JB.HOURLY_RT,
   JB.EFFDT, JB.EFFSEQ, JB.EMPL_RCD, JB.DEPTID, JB.SETID_JOBCODE, JB.ESTABID,
JB.SAL_ADMIN_PLAN, JB.FICA_STATUS_EE, JB.SETID_LOCATION
from
PS_JOB JB Where JB.EMPLID     = :1 AND JB.COMPANY = :2 AND JB.EFFDT =
(SELECT MAX(JB1.EFFDT) FROM   PS_JOB JB1 WHERE JB1.EMPLID    = JB.EMPLID
AND JB1.COMPANY   = JB.COMPANY AND JB1.EFFDT <= :3) AND JB.EFFSEQ = (SELECT
MAX(JB2.EFFSEQ) FROM PS_JOB JB2 WHERE JB2.EMPLID   = JB.EMPLID AND
JB2.COMPANY   = JB.COMPANY AND JB2.EFFDT     = JB.EFFDT) ORDER by JB.EFFDT,
JB.EFFSEQ
call     count       cpu    elapsed       disk      query    current        rows
Parse    14305      0.00       1.62          0          0          0           0
Execute 25852      0.00      62.80          0         44          0           0
Fetch    51704      0.00    2429.58     167169    1036420          0       25888
total    91861      0.00    2494.01     167169    1036464          0       25888
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 28
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
latch: shared pool                            242        9.08         66.46
latch: library cache                          108        5.78         61.32
latch: row cache objects                       23        0.06          0.20
SQL*Net message to client                   66009        0.00          0.00
SQL*Net message from client                 66009        0.00          0.00
db file sequential read                    167169        0.00          0.00
latch free                                      1        0.04          0.04
read by other session                           1        0.00          0.00
********************************************************************************The OEM tuning advisor does not recommend any tuning options for these.
Please advice.
For more information, please let me know.
Thanks
Suddhasatwa
Edited by: user13021719 on Mar 16, 2012 12:27 AM

Cache server-Content server

Hi,
    1. What is the procedure to copy originals from local content server to central content servers located at different geographical locations. (There is a report SAPKROTP, but i am unable to execute it). Even if copy it, will it display in DIR as two different files.
   2. About Cache server : As name implies it is a temp storage and based on reference from SAP help and few other documents, it is very clear that documents cannot be checked in cache server. Also We are not defining cache server in OAC0 and OACT settings. Hence Can we check-in originals in cache server?.
     If any of you have worked with multiple caching and multiple content server distributed environment, please mail me the document. My mail id is [email protected]
Prasanna
<b>Points will be awarded for useful answers</b>

Hi Prasanna,
A Cache Server is used to store copies of documents when they are accessed for the first time. As a result, the documents can be accessed again more quickly, since the contents are taken directly from the Cache.
With Cache the Originals documents are stored in one location on content server. The copies in the cache can be replaced with newer content at any time.
The Original document will still be located on the Content Server
The Content Server can Retrieve the cache Content at any time
As earlier i had told you that any number of content servers can be installed in different locations. The contents are transferred directly b/w the client & content server. If the Content server are accessed from different locations that are linked via WAN cache servers should be used.
You need to install one Cache Server at each location on WAN for enhancing the performance & Reducing the traffic in Network. So Cache server is used only for speeding up accesses of documents stored.
For Customizing the Multilayer Cache Servers & Content Servers follow this SAP NOTE <b>0216419</b>
Hope following this Note will help you & solve your problem.
Regards
Rehman
Reward Your Points If Useful

If sga_target set explicitly, result cache become disabled

hi all,
I am using 11g R2 and automatic memory management. I realized something. if I explicitly declare sga_target parameter in parameter file, result cache become disabled.
as you know if you use automatic memory management, sga_target is set to 0 automatically already but if I write that to the parameter file than whatever I set for result_cache_max_size parameter, instance always opens with result_cache_max_size=0 (I saw that in alert log).
is there any reason for that ?
here is my pfile contents.
orcl.__db_cache_size=922746880
orcl.__java_pool_size=33554432
orcl.__large_pool_size=16777216
orcl.__oracle_base='C:\app\paranoyakX'#ORACLE_BASE set from environment
orcl.__pga_aggregate_target=838860800
orcl.__sga_target=1258291200
orcl.__shared_io_pool_size=0
orcl.__shared_pool_size=251658240
orcl.__streams_pool_size=16777216
*.audit_file_dest='C:\app\paranoyakX\admin\orcl\adump'
*.audit_trail='DB_EXTENDED'
*.compatible='11.2.0.0.0'
*.control_files='C:\app\paranoyakX\oradata\orcl\control01.ctl','C:\app\paranoyakX\flash_recovery_area\orcl\control02.ctl'
*.db_16k_cache_size=0
*.db_4k_cache_size=0
*.db_block_size=8192
*.db_domain='oracle.com'
*.db_flashback_retention_target=1000
*.db_keep_cache_size=0
*.db_name='orcl'
*.db_recovery_file_dest='C:\app\paranoyakX\flash_recovery_area'
*.db_recovery_file_dest_size=10737418240
*.diagnostic_dest='C:\app\paranoyakX'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.memory_max_target=34359738368
*.memory_target=2097152000
*.nls_language='TURKISH'
*.nls_territory='TURKEY'
*.open_cursors=300
*.pga_aggregate_target=528482304
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_limit=TRUE
*.undo_tablespace='UNDOTBS1'
*.result_cache_max_size=5000000
*.sga_target=0

I would suggest that you pay more attention to documentation and don't jump to conclusion in a haste. Just because the parameter result_cache_max_size is set to 0, it does not mean that the result cache in itself is disabled. This is the maximum size of the result cache. See below,
[oracle@edbar2p0-orcl ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 14 08:35:00 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
SQL> sho parameter result
NAME                                 TYPE        VALUE
client_result_cache_lag              big integer 3000
client_result_cache_size             big integer 0
result_cache_max_result              integer     5
result_cache_max_size                big integer 1184K
result_cache_mode                    string      MANUAL
result_cache_remote_expiration       integer     0
SQL> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 460M
sga_target                           big integer 0
SQL> set autot trace exp
selSQL> ect /*+ result_cache */ * from scott.dept;
Execution Plan
Plan hash value: 3383998547
| Id | Operation          | Name                       | Rows | Bytes | Cost (
%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |     4 |    80 |     3
(0)| 00:00:01 |
|   1 | RESULT CACHE      | 1c13q1afp56bq0jpnmysvywx7g |       |       |
     |          |
|   2 |   TABLE ACCESS FULL| DEPT                       |     4 |    80 |     3
(0)| 00:00:01 |
Result Cache Information (identified by operation id):
   1 - column-count=3; dependencies=(SCOTT.DEPT); name="select /*+ result_cache
*/ * from scott.dept"
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing optionsThe value for the result_cache parameter is automatically set by oracle depending on either you have Memory_target/SGA_TARGET or Shared_Pool parameter set. Please see oracle documentation for more information.
HTH
Aman....

Result cache invalidated

Hi,
Oracle version 11.2.0.1 on Linux
I understand thatt result cache (RC) invalidation is at table level.
I did a simple test:
create table customer (custno number, custname varchar2(30));
Table created.
insert into customer (custno,custname) values (1,'Customer_1');
insert INTO CUSTOMER (custno,custname) values (2,'Customer_X');
select * from customer;
    CUSTNO CUSTNAME
         1 Customer_1
         2 Customer_X
commit;
Commit complete.Now I invoke result cache here
select /*+ RESULT_CACHE */ * FROM customer where custno=1;
Execution Plan
Plan hash value: 2844954298
| Id | Operation          | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |     1 |    30 |     3   (0)| 00:00:01 |
|   1 | RESULT CACHE      | ggb2vz6jcvcn5ajzqh406j3n85 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| CUSTOMER                   |     1 |    30 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("CUSTNO"=1)
Result Cache Information (identified by operation id):
   1 - column-count=2; dependencies=(SCRATCHPAD.CUSTOMER); name="select /*+ RESULT_CACHE */ * FROM customer where custno=1"Invoke RC for second row query
select /*+ RESULT_CACHE */ * FROM customer where custno=2;
Execution Plan
Plan hash value: 2844954298
| Id | Operation          | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |     1 |    30 |     3   (0)| 00:00:01 |
|   1 | RESULT CACHE      | fc8t6svvz6whh0gc8vcaxrh668 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| CUSTOMER                   |     1 |    30 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("CUSTNO"=2)
Result Cache Information (identified by operation id):
   1 - column-count=2; dependencies=(SCRATCHPAD.CUSTOMER); name="select /*+ RESULT_CACHE */ * FROM customer where custno=2"OK they are stored as separate result cache
Now update the second row in that table in another session
update customer set custname ='Customer_2' where custno=2;
1 row updated.
commit;
Commit complete.Now query custno=2 from the first session
select /*+ RESULT_CACHE */ * FROM customer where custno=2;
Execution Plan
Plan hash value: 2844954298
| Id | Operation          | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |     1 |    30 |     3   (0)| 00:00:01 |
|   1 | RESULT CACHE      | fc8t6svvz6whh0gc8vcaxrh668 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| CUSTOMER                   |     1 |    30 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("CUSTNO"=2)
Result Cache Information (identified by operation id):
   1 - column-count=2; dependencies=(SCRATCHPAD.CUSTOMER); name="select /*+ RESULT_CACHE */ * FROM customer where custno=2"The same result cache reference is still there. So does this mean that result cache is NOT invalidated despite the row being updated or I am doing something wrong here?
Thanks
Edited by: 902986 on 12-Feb-2012 13:26

The result cache id is a hash value for the query so that Oracle can later tell if a query will produce a result set that is already in the cache.
When you updated the table the result set in the cache was marked invalid. Then you ran the same query for record 2 and Oracle created a hash value for the query and the hash value is the same as the first time since the query is the same; that is, the query itself hashes to the same value. But the result cache contents for that query have changed and replace the old invalid contents.
If you query the result set cache you will get the new value not the old one since the old result set for your second query isn't there anymore.

Latch Contention issues

Hi,
We recently upgraded the oracle version from 9.07 to 9.08. Since the upgrade out application has been performing poorly. We spoke to the Oracle DBAs and they identified this to be a latch contention problem. They changed the cursor sharing from exact to similar. They even increased the buffer cache size. But we continue to have performance issues with the database.
Had anyone come across latch contention issues and how was it resolved? Is there is a bug in 9.08 version? Do we think of downgrading it back to 9.07?
Please suggest.

Hi,
shared pool housekeeping is not as simple as you imagine it to be. It's not like at any given moment of time there is only one "correct" child cursor, the rest being subject to purging, it's much more complex, and the exact housekeeping algorithms are not accessible to us users. Plus, you only have several child curors; I once had over a hundred and raised a SR to that effect -- the customer support represebtatuve said that cursor sharing mechanisms in Oracle aren't perfect and unless one has thousands of child cursors one shouldn't be worried.
Best regards,
Nikolay

Query result caching on oracle 9 and 10 vs indexing

I am trying to improve performance on oracle 9i and 10g.
We use some queries that take up to 30 minutes to execute.
I heard that there are some products to cache query results.
Would this have any advantage over using indexes or materialized views?
Does anyone know any products that I can use to cache the results of this queries on disk?
Personally I think that by using the query result caching I would reduce the cpu time needed to process the query.
Is this true?

Your message post pushes all the wrong buttons starting with the fact that 9i and 10g are marketing labels not version numbers.
You don't tune queries by spending money and throwing resources at them. You tune them by identifying the problem queries, running explain plans, visualizing their output using DBMS_XPLAN, and addressing the root cause.
If you want help post full version numbers, the SQL statements, and the DBMS_XPLAN outputs.

Oracle 11g result cache and TimesTen

Oracle 11g has introduced the concept of result cache whereby the result set of frequently executed queries are stored in cache and used later when other users request the same query. This is different from caching the data blocks and exceuting the query over and over again.
Tom Kyte calls this just-in-time materialized view whereby the results are dynamically evaluated without DBA intervention
http://www.oracle.com/technology/oramag/oracle/07-sep/o57asktom.html
My point is that in view of utilities like result_cache and possible use of Solid State Disks in Oracle to speed up physical I/O etc is there any need for a product like TimesTen? It sounds to me that it may just asdd another layer of complexity?

Oracle result cache ia a useful tool but it is distinctly different from TimesTen. My understanding of Oracle's result cache is caching results set for seldom changing data like look up tables (currencies ID/code), reference data that does not change often (list of counter parties) etc. It would be pointless for caching result set where the underlying data changes frequently.
There is also another argument for SQL result cache in that if you are hitting high on your use of CPUs and you have enough of memory then you can cache some of the results set thus saving on your CPU cycles.
Considering the arguments about hard wired RDBMS and Solid State Disks (SSD), we can talk about it all day but having SSD does not eliminate the optimiser consideration for physical I/O. A table scan is a table scan whether data resides on SCSI or SSD disk. SSD will be faster but we are still performing physical IOs.
With regard to TimesTen, the product positioning is different. TimesTen is closer to middletier than Oracle. It is designed to work closely to application layer whereas Oracle has much wider purpose. For real time response and moderate volumes there is no way one can substitue TimesTen with any hard wired RDBMS. The request for result cache has been around for sometime. In areas like program trading and market data where the underlying data changes rapidly, TimesTen will come very handy as the data is real time/transient and the calculations have to be done almost realtime, with least complications from the execution engine. I fail to see how one can deploy result cache in this scenario. Because of the underlying change of data, Oracle will be forced to calculate the queries almost everytime and the result cache will be just wasted.
Hope this helps,
Mich

Oracle 11g/R2 Query Result Cache - Incremental Update

Hi,
In Oracle 11g/R2, I created replica of HR.Employees table & executed the following statement (+Although using SUM() function is non-logical in this case, but just testifying the result+)
STEP - 1
SELECT      /+ RESULT_CACHE */ employee_id, first_name, last_name, SUM(salary)*
FROM           HR.Employees_copy
WHERE      department_id = 20
GROUP BY      employee_id, first_name, last_name;
EMPLOYEE_ID      FIRST_NAME LAST_NAME     SUM(SALARY)
202           Pat           Fay          6000
201           Michael           Hartstein     13000
Elapsed: 00:00:00.01
Execution Plan
Plan hash value: 3837552314
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT      | | 2 | 130 | 4 (25)| 00:00:01 |
| 1 | RESULT CACHE      | 3acbj133x8qkq8f8m7zm0br3mu | | | | |
| 2 | HASH GROUP BY      | | 2 | 130 | 4 (25)| 00:00:01 |
|* 3 | TABLE ACCESS FULL     | EMPLOYEES_COPY | 2 | 130 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------     Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
*690* bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
STEP - 2
INSERT INTO HR.employees_copy
VALUES(200, 'Dummy', 'User','[email protected]',NULL, sysdate, 'MANAGER',5000, NULL,NULL,20);
STEP - 3
SELECT      /*+ RESULT_CACHE */ employee_id, first_name, last_name, SUM(salary)
FROM           HR.Employees_copy
WHERE      department_id = 20
GROUP BY      employee_id, first_name, last_name;
EMPLOYEE_ID      FIRST_NAME LAST_NAME SUM(SALARY)
202      Pat      Fay      6000
201      Michael      Hartstein      13000
200      Dummy User      5000
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 3837552314
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT |          | 3 | 195 | 4 (25)| 00:00:01 |
| 1 | RESULT CACHE | 3acbj133x8qkq8f8m7zm0br3mu | | | | |
| 2 | HASH GROUP BY | | 3 | 195 | 4 (25)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| EMPLOYEES_COPY | 3 | 195 | 3 (0)| 00:00:01 |
     Statistics
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
*714* bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
In the execution plan of STEP-3, against ID-1 the operation RESULT CACHE is shown which shows the result has been retrieved directly from Result cache. Does this mean that Oracle Server has Incrementally Retrieved the resultset?
Because, before the execution of STEP-2, the cache contained only 2 records. Then 1 record was inserted but after STEP-3, a total of 3 records was returned from cache. Does this mean that newly inserted row is retrieved from database and merged to the cached result of STEP-1?
If Oracle server has incrementally retrieved and merged newly inserted record, what mechanism is being used by the Oracle to do so?
Regards,
Wasif
Edited by: 965300 on Oct 15, 2012 12:25 AM

965300 wrote:
Hi,
In Oracle 11g/R2, I created replica of HR.Employees table & executed the following statement (+Although using SUM() function is non-logical in this case, but just testifying the result+)
STEP - 1
SELECT      /+ RESULT_CACHE */ employee_id, first_name, last_name, SUM(salary)*
FROM           HR.Employees_copy
WHERE      department_id = 20
GROUP BY      employee_id, first_name, last_name;
EMPLOYEE_ID      FIRST_NAME LAST_NAME     SUM(SALARY)
202           Pat           Fay          6000
201           Michael           Hartstein     13000
Elapsed: 00:00:00.01
Execution Plan
Plan hash value: 3837552314
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT      | | 2 | 130 | 4 (25)| 00:00:01 |
| 1 | RESULT CACHE      | 3acbj133x8qkq8f8m7zm0br3mu | | | | |
| 2 | HASH GROUP BY      | | 2 | 130 | 4 (25)| 00:00:01 |
|* 3 | TABLE ACCESS FULL     | EMPLOYEES_COPY | 2 | 130 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------     Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
*690* bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
STEP - 2
INSERT INTO HR.employees_copy
VALUES(200, 'Dummy', 'User','[email protected]',NULL, sysdate, 'MANAGER',5000, NULL,NULL,20);
STEP - 3
SELECT      /*+ RESULT_CACHE */ employee_id, first_name, last_name, SUM(salary)
FROM           HR.Employees_copy
WHERE      department_id = 20
GROUP BY      employee_id, first_name, last_name;
EMPLOYEE_ID      FIRST_NAME LAST_NAME SUM(SALARY)
202      Pat      Fay      6000
201      Michael      Hartstein      13000
200      Dummy User      5000
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 3837552314
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT |          | 3 | 195 | 4 (25)| 00:00:01 |
| 1 | RESULT CACHE | 3acbj133x8qkq8f8m7zm0br3mu | | | | |
| 2 | HASH GROUP BY | | 3 | 195 | 4 (25)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| EMPLOYEES_COPY | 3 | 195 | 3 (0)| 00:00:01 |
     Statistics
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
*714* bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
In the execution plan of STEP-3, against ID-1 the operation RESULT CACHE is shown which shows the result has been retrieved directly from Result cache. Does this mean that Oracle Server has Incrementally Retrieved the resultset?
Because, before the execution of STEP-2, the cache contained only 2 records. Then 1 record was inserted but after STEP-3, a total of 3 records was returned from cache. Does this mean that newly inserted row is retrieved from database and merged to the cached result of STEP-1?
If Oracle server has incrementally retrieved and merged newly inserted record, what mechanism is being used by the Oracle to do so?
Regards,
Wasif
Edited by: 965300 on Oct 15, 2012 12:25 AMNo, the RESULT CACHE operation doesn't necessarily mean that the results are retrieved from there. It could be being
written to there.
Look at the number of consistent gets: it's zero in the first step (I assume you had already run this query before) and I would
conclude that the data is being read from the result cache.
In the third step there are 4 consistent gets. I would conclude that the data is being written to the result cache, a fourth step repeating
the SQL should show zero consistent gets and that would be the results being read.

Function result Cache in oracle 11G

Hi,
i am reading the following article and trying to reproduce same set of statements to learn about function result cache.
http://www.oracle.com/technology/oramag/oracle/07-sep/o57asktom.html
Details about my output:
SQL> create or replace
function not_cached
( p_owner in varchar2 )
return number
as
l_cnt number;
begin
select count(*)
into l_cnt
from t
where owner = p_owner;
sys.dbms_lock.sleep(1);
return l_cnt;
end;
Function created.
Elapsed: 00:00:00.13
SQL> create or replace
function cached
( p_owner in varchar2 )
return number
result_cache
relies_on(T)
as
l_cnt number;
begin
select count(*)
into l_cnt
from t
where owner = p_owner;
dbms_lock.sleep(1);
return l_cnt;
end;
Function created.
Elapsed: 00:00:00.08
SQL> exec dbms_output.put_line( not_cached( 'SCOTT' ) );
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.06
SQL> exec dbms_output.put_line( not_cached( 'SCOTT' ) );
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.01
SQL> SQL> exec dbms_output.put_line( not_cached( 'SCOTT' ) );
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.02
SQL> SQL> set serveroutput on
SQL> exec dbms_output.put_line( not_cached( 'SCOTT' ) );
0
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.02
SQL> SQL> exec dbms_output.put_line( cached( 'SCOTT' ) );
0
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.02
SQL> SQL> exec dbms_output.put_line( cached( 'SCOTT' ) );
0
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.02
SQL> SQL> exec dbms_output.put_line( cached( 'SCOTT' ) );
0
PL/SQL procedure successfully completed.
SQL> exec dbms_output.put_line( cached( 'SCOTT' ) );
0
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.01
I am supposed to get the results quickly for "cached" call. However, i still dont see any change in the response time. May i know what i am missing here?
Thank you
Giridhar

Try to play with
RESULT_CACHE_MAX_SIZE
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams206.htm#REFRN10272
RESULT_CACHE_MAX_RESULT
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams205.htm#REFRN10298

Using the Client Result Cache

Hello everyone,
I have a question regarding the use of the client result cache but first of all here are the informations about my database:
SQL> SELECT * FROM v$version;
BANNER
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
I have installed the Oracle Client Tools on my clientmachine. It has a tnsnames.ora like this:
ORCL =
(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = FEA11-119SRV)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = orcl.local)
The Client Result Cache is configured in the sqlnet.ora.
ADR_BASE = /u01/app/oracle
OCI_RESULT_CACHE_MAX_SIZE= 2048000
OCI_RESULT_CACHE_MAX_RSET_SIZE = 1024000
NAMES.DIRECTORY_PATH = (EZCONNECT, TNSNAMES, HOSTNAME)
The Databaseserver is configured like that:
SQL> col name format a30
SQL> col value format a30
SQL> SELECT name, value
2 FROM   v$system_parameter
3 WHERE name LIKE '%result_cache%';
NAME                   VALUE
result_cache_mode           MANUAL
result_cache_max_size           0
result_cache_max_result        5
result_cache_remote_expiration 0
client_result_cache_size       1073741824
client_result_cache_lag        3000
After configuring client an server I try the followign SQL-Statement on the clientmachine:
sqlplus oracle/password@orcl
set autotrace traceonly explain
SELECT /*+ result_cache */ *
FROM testtable;
SQL
The execution plan show two operations: "SELECT STATEMENT" and "TABLE ACCESS FULL" but no the "RESULT CACHE" operation.
Did I miss something?
Any help would be appreciated
Florian W.

result_cache_max_size           0
That means the result cache is disabled. You need to set it to a non-zero value. That is the maximum ammount of memory, in bytes, the database will allocate on the shared pool to dedicate it to the result cache for all requests.
By the way, OCI_RESULT_CACHE_MAX_SIZE is optional. By default the sessions will have the maximum size they can occupy on the cache determined by CLIENT_RESULT_CACHE parameter, the client (OCI) side parameters override that.
result_cache_mode           MANUAL
Another thing to consider is RESULT_CACHE_MODE in MANUAL, that will cause only the statements with the RESULT_CACHE hint on it to be cached on the result cache. You can also set result cache to mode FORCE on specific tables with alter table command.
Regards

SQL Result Cache vs In-Memory Database Cache

Hi,
can anyone help me to understand the relations and differences between the 11 g new features of SQL Result Cache vs In-Memory Database Cache ?
Thanks

I highly recommend you read the 11g New Features Guide. Here is a sample from it:
h4. 1.11.2.9 Query Result Cache
A separate shared memory pool is now used for storing and retrieving
cached results. Query retrieval from the query result cache is faster
than rerunning the query. Frequently executed queries will see
performance improvements when using the query result cache.
The new query result cache enables explicit caching of results in
database memory. Subsequent queries using the cached results will
experience significant performance improvements.
See Also:
[Oracle Database Performance Tuning Guide|http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/memory.htm#PFGRF10121] for details
[Results Cache Concepts|http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/memory.htm#PFGRF10121|Results Cache Concepts]
HTH!

Result Cache in oracle 11g release 2.0.2.0

All,
Few months back I was trying Result Cache feature of 11g release 2.0.1.0. That time oracle mentioned that they have 3 modes to use this feature by setting result_cache_mode paramter to AUTO, FORCE or MANUAL. With AUTO mode (result_cache_mode=AUTO) you can identify queries that may benefit from result cache. I would like to know whcih views or function I should see where it captures this information.
In 11.2.0.1.0 documentation it was referencing some views (I totally don't remember those views names) and said those will be available in 11.2.0.2.0.
Is anyone know about this?
Thanks in advance.

user2486753 wrote:
Though oracle doc doesn't say about AUTO it is still accepts that value and caches the result of the SQL query if you add /*+ result cache */ hint to the SQL.
I know that they did mentioned in 112010 some where that it will help users to find which SQL's are good candidates for caching by running the application for a while. I just couldn't fine it.If we are adding AUTO and still passing the hint, its the same behavior as like MANUAL. I am not sure that I have seen the value anywhere and neither its there in the docs too.
HTH
Aman....

Oracle result cache and functions

Hi All,
I am on 11.2 in Linux.
I want to use Oracle's result cache to cache results of (user defined) functions, which we use in SELECT commands.
My question is, does result caching work for deterministic and non-deterministic functions ?
Just curious, how Oracle keeps track of changes being made which affect a function's return value?
Thoughts please.
Thanks in advance

I want to ... cache results of (user defined) functions, which we use in SELECT commands.You have four choices:
1. Subquery caching - (wrap function call in SELECT) useful for repeated function calls in a single SELECT
2. Marking function as DETERMINISTIC - inconsistent results across versions, deterministic best reserved for function-based indexes only
3. Result Cache
4. Move function logic out of function and inline to the main SQL statement.
The biggest downside of any function call that is inline to SQL is that it bypasses the read consistency mechanism, actually that's probably the second biggest downside. The biggest downside is normally that their misuse kills performance.
If your function itself contains SQL then you should seriously reconsider whether you should be using a function.
does result caching work for deterministic and non-deterministic functions ?Result cache knows nothing about determinism so yes it should be applied regardless.
Oracle keeps track of changes being made which affect a function's return value?See v$result_cache_dependency.
The mechanism is very blunt, there is no fine-grained tracking of data changes that may affect your result.
It's as simple as function F1 relies on table T1. If the data in table T1 changes, invalidate the results in the result cache for F1.

Result cache latch contention

Similar Messages

Maybe you are looking for