Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Result Caching in Oracle 11g

Result Caching in Oracle 11g

Ratings: (0)|Views: 22|Likes:
Published by sudhakaran_18
Result caching in oracle 11G
Result caching in oracle 11G

More info:

Categories:Types, Research, Science
Published by: sudhakaran_18 on Sep 22, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

08/26/2013

pdf

text

original

 
QUERY RESULT CACHE IN ORACLE 11G
Caching has been a feature of Oracle for as long as most of us can remember. Over the many years and versions, Oracle has continually expanded its caching mechanisms. We are allfamiliar with the buffer cache, keep cache, library cache, shared pool, PGA/UGA and so on. In addition to the many data and cursor caches included in its architecture, Oracle has alsoenhanced caching support for common programming techniques; for example, scalar subquery caching, global temporary tables and associative arrays. In 11g, Oracle has extendedthis further by adding result caching to both its server and client architecture.There are three new result caching features in 11g:
query result cache;
PL/SQL function result cache; and
client OCI result cache.This article will describe and demonstrate the query result cache only. The PL/SQL function result cache feature shares much of the same architecture, but will be the subject of afuture article.
an overview
As its name suggests, the query result cache is used to store the results of SQL queries for re-use in subsequent executions. By caching the results of queries, Oracle can avoid havingto repeat the potentially time-consuming and intensive operations that generated the resultset in the first place (for example, sorting/aggregation, physical I/O, joins etc). The cacheresults themselves are available across the instance (i.e. for use by sessions other than the one that first executed the query) and are maintained by Oracle in a dedicated area of memory. Unlike our homegrown solutions using associative arrays or global temporary tables, the query result cache is completely transparent to our applications. It is also maintainedfor consistency automatically, unlike our own caching programs.We will examine the features of the query result cache in more detail throughout this article.
database configuration
We will begin by looking at some of the database configuration required to use the query result cache. The initialisation parameters are as follows.
SQL> SELECT name, value, isdefault2 FROM v$parameter3 WHERE name LIKE 'result_cache%';NAME VALUE ISDEFAULT---------------------------------- ------------------ ---------result_cache_mode MANUAL TRUEresult_cache_max_size 1081344 TRUEresult_cache_max_result 5 TRUEresult_cache_remote_expiration 0 TRUE4 rows selected.
A brief explanation of each of these parameters is as follows.
result_cache_mode:
the result cache can be enabled in three ways: via hint, alter session or alter system. Default is MANUAL which means that we need to explicitlyrequest caching via the RESULT_CACHE hint;
result_cache_max_size:
this is the size of the result cache in bytes. The cache is allocated directly from the shared pool but is maintained separately (for example,flushing the shared pool will not flush the result cache);
result_cache_max_result:
this specifies the highest percentage of the cache that is able to be used by a single resultset (default 5%); and
result_cache_remote_expiration:
this specifies the number of minutes for which a resultset based on a remote object can remain valid. The default is 0 which meansthat resultsets dependant on remote objects will not be cached.The cache size is dynamic and can be changed either permanently or until the instance is restarted. We will roughly double the size of the cache for this article and verify that we havea larger result cache as follows (note this was run as SYSDBA).
SQL> ALTER SYSTEM SET result_cache_max_size = 2M SCOPE = MEMORY;System altered.SQL> SELECT name, value2 FROM v$parameter3 WHERE name = 'result_cache_max_size';NAME VALUE---------------------------------------- -------------------------result_cache_max_size 20971521 row selected.
 
The setup for the result cache is simple and should be a one-time DBA operation. We will now see some examples of caching and using results below.
caching results manually
As we saw earlier, the default caching mode for this instance is MANUAL. This means that query resultsets will not be cached unless we instruct Oracle to do so by using theRESULT_CACHE hint. In our first example below, we will manually cache the results of a simple aggregate query. Note that the examples in this article are all based on the SHsample schema. First, we verify our cache mode as follows.
SQL> SELECT value2 FROM v$parameter3 WHERE name = 'result_cache_mode';VALUE----------------MANUAL1 row selected.
We will now run a query and cache its results. We will run this through Autotrace because we are interested in both the workload statistics and the execution plan (Autotrace will alsoconveniently suppress the query output).
SQL> set autotrace traceonlySQL> set timing onSQL> SELECT /*+ RESULT_CACHE */2 p.prod_name3 , SUM(s.amount_sold) AS total_revenue4 , SUM(s.quantity_sold) AS total_sales5 FROM sales s6 , products p7 WHERE s.prod_id = p.prod_id8 GROUP BY9 p.prod_name;71 rows selected.
Elapsed: 00:00:05.00
Using the RESULT_CACHE hint, we have instructed Oracle to cache the results of this aggregate query. We can see that it returned 71 rows and took 5 seconds to execute. We willsee the amount of work that Oracle did to generate these results further below, but first we will see the execution plan (note that this is a theoretical explain plan and not the realexecution plan, but is a good approximation in this system).
Execution Plan----------------------------------------------------------Plan hash value: 504757596----------------------------------------------------------------------- ... -----------------| Id | Operation | Name | Rows | ... | Pstart| Pstop |----------------------------------------------------------------------- ... -----------------| 0 | SELECT STATEMENT | | 71 | ... | | |
| 1 | RESULT CACHE | 091zc7mvn8ums36mbd2gqac4h0 | | ... | | |
| 2 | HASH GROUP BY | | 71 | ... | | ||* 3 | HASH JOIN | | 72 | ... | | || 4 | VIEW | VW_GBC_5 | 72 | ... | | || 5 | HASH GROUP BY | | 72 | ... | | || 6 | PARTITION RANGE ALL| | 918K| ... | 1 | 28 || 7 | TABLE ACCESS FULL | SALES | 918K| ... | 1 | 28 || 8 | TABLE ACCESS FULL | PRODUCTS | 72 | ... | | |----------------------------------------------------------------------- ... -----------------Predicate Information (identified by operation id):---------------------------------------------------3 - access("ITEM_1"="P"."PROD_ID")
Result Cache Information (identified by operation id):------------------------------------------------------1 - column-count=3; dependencies=(SH.SALES, SH.PRODUCTS); parameters=(nls); name="SELECT /*+ RESULT_CACHE */p.prod_name, SUM(s.amount_sold) AS total_revenue, SUM(s.quantity_sold) AS total_"
 Note the highlighted sections of the execution plan. It contains some new information, which we can summarise as follows:
first, we can see a new operation, "RESULT CACHE" at operation ID=1. This is the last step in this particular example and it is telling us that Oracle will cache theresults of the preceding operations;
 
second, we see a system-generated name beside the RESULT CACHE operation. This is used internally as a key for looking up and matching SQL statements to their cached results;
third, we see a new section in the plan report on the result cache metadata for this query. This section includes information such as the objects that the results aredependant on (i.e. to maintain cache coherency) and the leading part of the SQL text that generated the results.Finally, the Autotrace report displays the work that Oracle performed to generate these results.
Statistics----------------------------------------------------------14871 recursive calls0 db block gets4890 consistent gets1745 physical reads0 redo size3526 bytes sent via SQL*Net to client416 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client136 sorts (memory)0 sorts (disk)71 rows processed
We can see a range of I/O and CPU activity in these figures, as expected. We will now test the new query result cache by running the same query a second time and comparing theAutotrace report, as follows.
SQL> SELECT /*+ RESULT_CACHE */2 p.prod_name3 , SUM(s.amount_sold) AS total_revenue4 , SUM(s.quantity_sold) AS total_sales5 FROM sales s6 , products p7 WHERE s.prod_id = p.prod_id8 GROUP BY9 p.prod_name;71 rows selected.
Elapsed: 00:00:00.01
Execution Plan----------------------------------------------------------Plan hash value: 504757596----------------------------------------------------------------------- ... -----------------| Id | Operation | Name | Rows | ... | Pstart| Pstop |----------------------------------------------------------------------- ... -----------------| 0 | SELECT STATEMENT | | 71 | ... | | || 1 | RESULT CACHE | 091zc7mvn8ums36mbd2gqac4h0 | | ... | | || 2 | HASH GROUP BY | | 71 | ... | | ||* 3 | HASH JOIN | | 72 | ... | | || 4 | VIEW | VW_GBC_5 | 72 | ... | | || 5 | HASH GROUP BY | | 72 | ... | | || 6 | PARTITION RANGE ALL| | 918K| ... | 1 | 28 || 7 | TABLE ACCESS FULL | SALES | 918K| ... | 1 | 28 || 8 | TABLE ACCESS FULL | PRODUCTS | 72 | ... | | |----------------------------------------------------------------------- ... -----------------Predicate Information (identified by operation id):---------------------------------------------------3 - access("ITEM_1"="P"."PROD_ID")Result Cache Information (identified by operation id):------------------------------------------------------1 - column-count=3; dependencies=(SH.SALES, SH.PRODUCTS); parameters=(nls); name="SELECT /*+ RESULT_CACHE */p.prod_name, SUM(s.amount_sold) AS total_revenue, SUM(s.quantity_sold) AS total_"Statistics----------------------------------------------------------
0 recursive calls0 db block gets0 consistent gets0 physical reads0 redo size
3526 bytes sent via SQL*Net to client416 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client
0 sorts (memory)0 sorts (disk)
71 rows processed

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->