See How Easily You Can

Improve Performance by
Using These Five Data
Caching Techniques
Eddie Awad
7/17/2012

Data caching is commonly used to optimize access to data that is static for a period of time. In this
paper, you will learn how to apply SQL and PL/SQL data caching techniques that will considerably
improve the performance of your queries and programs. The paper covers SQL Query Result Cache,
PL/SQL Function Result Cache, Package-Based Cache, Deterministic Function Cache and Scalar Subquery
Cache.
Table of Contents
Introduction ............................................................................................................................ 3
Server Result Cache .............................................................................................................. 3
Initialization Parameters ...................................................................................................... 4
DBMS_RESULT_CACHE Package .................................................................................... 4
Dynamic Performance Views .............................................................................................. 4
SQL Query Result Cache ....................................................................................................... 5
RESULT_CACHE and NO_RESULT_CACHE Hints ........................................................... 6
RESULT_CACHE Table Annotation.................................................................................... 7
Inline View SQL Result Cache ............................................................................................ 7
Considerations .................................................................................................................... 8
PL/SQL Function Result Cache .............................................................................................. 8
RESULT_CACHE and RELIES_ON.................................................................................... 9
When to use the function result cache ................................................................................ 9
Considerations: ..................................................................................................................10
Deterministic Function Cache ................................................................................................10
When to use deterministic functions ...................................................................................11
Package-Based Cache ..........................................................................................................11
Consider using a package-based cache when: ..................................................................11
Do not use a package-based cache if: ...............................................................................11
Scalar Subquery Cache .........................................................................................................12
Definition of a Scalar Subquery ..........................................................................................12
About the Author ...................................................................................................................13
Introduction
The word cache comes from the French word meaning to hide1. Wikipedia defines cache as
a component that transparently stores data so that future requests for that data can be served
faster2. Cached data is stored in the memory. Reading data from memory is much faster than
reading it from a hard disk. Caching is an essential and widely used performance optimization
technique.

Data caching is used in all types of applications and systems. CPUs use cache, disks use
cache, web browsers use cache, search engines use cache, databases use cache.

Oracle supports data caching in many ways. Oracles system global area (SGA) memory
structure is a collection of many caches like the buffer cache, keep cache, library cache, shared
pool, PGA/UGA and so on.

This paper focuses on the following five data caching techniques, examines how to use them
and looks at their pros and cons, their use cases and more:

SQL Query Result Cache

PL/SQL Function Result Cache
Deterministic Function Cache
Package-Based Cache
Scalar Subquery Cache

These SQL and PL/SQL caching techniques considerably improve the performance of your
queries and programs.

Server Result Cache

Starting with Oracle database 11g, the SGA has had a new memory structure called the server
result cache [See Figure 1]. It is a memory pool within the shared pool. This pool contains a
SQL query result cache, which stores results of SQL queries, and a PL/SQL function result
cache, which stores values returned by PL/SQL functions3. Both of these result caches are
explained later in this document.

You can manage memory for the server result cache by setting database initialization
parameters and by using the DBMS_RESULT_CACHE package. You can also query dynamic
performance views to obtain information about the result cache.

The result cache feature is only available in the Enterprise Edition of the Oracle Database4.

1
http://dictionary.reference.com/browse/cache
2
http://en.wikipedia.org/wiki/Cache_%28computing%29
3
http://docs.oracle.com/cd/E11882_01/server.112/e16638/memory.htm#BGBIIBGE
4
http://docs.oracle.com/cd/E11882_01/license.112/e10594/editions.htm#CJACGHEB
Initialization Parameters
RESULT_CACHE_MAX_SIZE: This parameter sets the memory allocated to the server
result cache. The server result cache is enabled unless you set this parameter to 0, in
which case the cache is disabled.
RESULT_CACHE_MAX_RESULT: This parameter sets the maximum amount of server
result cache memory that can be used for a single result. The default is 5%, but you can
specify any percentage value between 1 and 100. You can set this parameter at the
system or session level.
RESULT_CACHE_REMOTE_EXPIRATION: This parameter specifies the expiration
time for a result in the server result cache that depends on remote database objects.
The default value is 0 minutes, which implies that results using remote objects should
not be cached.
RESULT_CACHE_MODE: This parameter specifies when a ResultCache operator is
spliced into a query's execution plan. Values can be MANUAL or FORCE. The default is
MANUAL. You can set this parameter at the system or session level.

DBMS_RESULT_CACHE Package
The DBMS_RESULT_CACHE package provides statistics, information, and operators that
enable you to manage memory allocation for the server result cache. You can use it to perform
operations such as bypassing the cache, retrieving statistics on the cache memory usage,
flushing the cache, and so on. Here is a summary of DBMS_RESULT_CACHE subprograms:

BYPASS procedure: Sets the bypass mode for the Result Cache
FLUSH function & procedure: Attempts to remove all the objects from the Result Cache,
and depending on the arguments retains or releases the memory and retains or clears
the statistics
INVALIDATE functions & procedures: Invalidates all the result-set objects that
dependent upon the specified dependency object
INVALIDATE_OBJECT functions & procedures: Invalidates the specified result-set
object(s)
MEMORY_REPORT procedure: Produces the memory usage report for the Result
Cache
STATUS function: Checks the status of the Result Cache

Refer to the Oracle Database documentation for detailed information on the

DBMS_RESULT_CACHE package.

Dynamic Performance Views

V$RESULT_CACHE_STATISTICS: Lists various server result cache settings and
memory usage statistics.
V$RESULT_CACHE_MEMORY: Lists all the memory blocks in the server result cache
and their corresponding statistics.
 V$RESULT_CACHE_OBJECTS: Lists all the objects whose results are in the server
result cache along with their attributes.
V$RESULT_CACHE_DEPENDENCY: Lists the dependency details between the results
in the server cache and dependencies among these results.

5
Figure 1 - Result Cache in the SGA

SQL Query Result Cache

The SQL query result cache enables explicit caching of query result sets and query fragments in
database memory, more specifically in the server result cache area of the shared pool (See
above). The cache is available across the instance for use by sessions other than the one that
first executed the query.

5
http://docs.oracle.com/cd/E11882_01/server.112/e25789/memory.htm#CHDHAHIJ
Figure 2 - SQL Query Result Cache

In Figure 2 above, when the first session executes a query for the first time and the query is
enabled for result cache, it retrieves the data from the database and then caches the result in
the SQL query result cache. When a second session executes the exact same query, it
retrieves the result directly from the cache instead of using the disks cutting down the execution
time by order of magnitude.

The query results stored in this cache become invalid when data in the database objects being
accessed by the query is modified. The process of caching the result set and invalidating the
cache is automatic and completely transparent to the application.

If the initialization parameter RESULT_CACHE_MAX_SIZE is set to 0 then the result cache is

disabled. The default value of this parameter depends on the SGA configured and the Memory
management system:
0.25% of MEMORY_TARGET or
0.5% of SGA_TARGET or
1% of SHARED_POOL_SIZE

When the result cache is enabled, Oracle manages the result cache mechanism based on the
value of RESULT_CACHE_MODE initialization parameter. The default caching mode is
MANUAL (RESULT_CACHE_MODE = MANUAL). So, by default, Oracle will cache the result
set of a query only when you use the RESULT_CACHE hint in the query.

RESULT_CACHE and NO_RESULT_CACHE Hints

When adding the RESULT_CACHE hint, you can see the RESULT CACHE operation in the
execution plan of the query. When you execute the query, Oracle looks up the result cache
memory to check for the existence of the result in the cache. If it exists, then the result will be
retrieved from the cache. If it doesnt, the query is executed and the result is cached in the result
cache along with returning the results (See Figure 2).

When RESULT_CACHE_MODE initialization parameter is set to FORCE and we do not want to

use the query result cache, then you use the NO_RESULT_CACHE hint in the query.
RESULT_CACHE Table Annotation
In 11g Release 2, Oracle added a new clause to the CREATE TABLE statement to control
result caching. This option can come in handy when it is not always feasible or possible to make
application level changes such as adding a hint to a SELECT statement.

Use this clause to determine whether the results of statements or query blocks that name this
table are considered for storage in the result cache. Two modes of result caching are available:
DEFAULT (default option) or FORCE.

If at least one table in a query is set to DEFAULT, result caching is not enabled at the table level
for this query, unless the RESULT_CACHE_MODE initialization parameter is set to FORCE or
the RESULT_CACHE hint is specified. This is the default if you omit this clause.

If all the tables of a query are marked as FORCE, the query result is considered for caching
unless the NO_RESULT_CACHE hint is specified for the query.

The RESULT_CACHE and NO_RESULT_CACHE SQL hints take precedence over these result
cache table annotations and the RESULT_CACHE_MODE initialization parameter. The
RESULT_CACHE_MODE setting of FORCE in turn takes precedence over this table annotation
clause.

Inline View SQL Result Cache

You can also use SQL Result Cache in inline views. Consider the following query:

SELECT prod_subcategory,revenue
FROM (SELECT /*+ RESULT_CACHE */ p.prod_category,
p.prod_csubategory,
sum(s.amount_sold) revenue
FROM products p, sales s
WHERE s.prod_id=p.prod_id and
s.time_id BETWEEN to_date('01-JAN-2006','dd-MON-yyyy')
and
to_date('31-DEC-2006','dd-MON-yyyy')
GROUP BY ROLLUP(p.prod_category,p.prod_subcategory))
WHERE prod_category = 'Women';

In the example given above, the RESULT_CACHE hint is used in the in-line view. In this case,
the following optimizations are disabled: view merging, predicate pushdown and column
projection. This is at the expense of the initial query, which might take a longer time to execute
the first time. However, subsequent executions will be much faster because of the SQL query
cache. The other benefit in this case is that similar queries (queries using a different predicate
value for prod_category in the last WHERE clause) will also be much faster.
Considerations6
Result cache is disabled for queries containing:
o Temporary or Dictionary tables
o Nondeterministic PL/SQL functions
o Sequence CURRVAL and NEXTVAL
o SQL functions CURRENT_DATE,SYSDATE,SYS_GUID, and so on
DDL/DML on remote database does not expire cached results
Flashback queries can be cached
Result Cache does not automatically release memory
o It grows until maximum size is reached
o DBMS_RESULT_CACHE.FLUSH purges memory
Bind variables
o Cached result is parameterized with variable values
o Cached results can only be found for the same variable values
Cached result will not be built if:
o Query is built on a noncurrent version of data (read consistency enforcement)
o Current session has outstanding transaction on tables in query

PL/SQL Function Result Cache

Starting with Oracle Database 11g, Oracle has implemented function result cache. This feature
provides a supported and system managed means for caching the results of PL/SQL functions
in the server result cache (See Figure 1).

Here is a description of this feature:

Each functions distinct input and return values are stored in a separate cache.
The cache is instance wide and available for use by all connected sessions. Starting with
Oracle Database 11gR2, the function result cache is shared across all RAC instances.
When a function is enabled for result cache and is called for the first time, Oracle
executes the function and then caches the return value in the result cache. When a
second session executes the same function with the same parameter values, it retrieves
the result directly from the cache instead of re-executing the function, cutting down the
execution time by order of magnitude.
When tables that are identified as dependencies for the cache are updated, the cache is
automatically invalidated. The next time the function is called the cache is refreshed with
consistent data.
Oracle builds the cache whether the function is called from inside a SQL statement or
from a PL/SQL block.

The Function Result Cache and Query Result Cache share the same components. They both
use the same Server Result Cache, RESULT_CACHE_% initialization parameters and
V$RESULT_CACHE_% views.

6
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=BULLETIN&id=1108133.1
RESULT_CACHE and RELIES_ON
To make a function result-cached, do the following:

In the function declaration, include the option RESULT_CACHE.

In the function definition:
o Include the RESULT_CACHE clause.
o In the optional RELIES_ON clause, specify any tables or views on which the
function results depend.
For example:

Standalone function with optional RELIES_ON:

CREATE OR REPLACE FUNCTION nbr_of_emps RETURN NUMBER

RESULT_CACHE RELIES_ON (dept);

Packaged function with optional RELIES_ON:

CREATE OR REPLACE PACKAGE util_pkg

IS
FUNCTION nbr_of_emps RETURN NUMBER
RESULT_CACHE;
END util_pkg;
/

CREATE OR REPLACE PACKAGE BODY util_pkg

IS
FUNCTION nbr_of_emps RETURN NUMBER
RESULT_CACHE RELIES_ON (dept)
IS
BEGIN
...
END nbr_of_emps;
END util_pkg;
/

RELIES_ON may appear only in the body. The use of the RELIES_ON clause is deprecated in
11gR2. Although it is still legal syntax, RELIES_ON shouldn't be used in 11gR2 and above.
Instead of using the tables specified in the clause Oracle uses the actual tables used by the
function (during execution) and uses these as the dependencies for the cached result.7

When to use the function result cache

Consider caching the result of a function when:
7
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1142314.1
 A function relies on a table or view whose data is either static or queried more frequently
than it is updated.
A function is called repeatedly with the same input values.

Considerations:
You cannot use the RESULT_CACHE clause if any of the following are true:
o The function is a pipelined table function.
o The function has any OUT or IN OUT parameters.
o Any of the functions IN parameters or RETURN type is of any of these types:
BLOB, CLOB, NCLOB, REF CURSOR, collection, record, object type.
o The function is an invoker rights function (defined with the AUTHID
CURRENT_USER clause).
Avoid using the RESULT_CACHE clause if:
o The function has side effects (modifies the state of the application).
o The function queries a table on which a Virtual Private Database security policy
applies.
When checking to see if the function has been called previously with the same inputs,
Oracle considers NULL to be equal to NULL.
Users never see dirty (uncommitted) data.
When you define a functions cache as dependent on a particular table, then when that
table is marked invalid, the function is also marked invalid and will need to be recompiled
before it can be used.
If the function propagates an unhandled exception, the database will not cache the input
values for that execution.

Deterministic Function Cache

A deterministic function returns the same result whenever it is called with the same values for its
IN and IN OUT arguments.

A deterministic function depends solely on the values passed into it as arguments and does not
reference or modify the contents of package variables or the database. In other words, it has no
side-effects.

This is what Oracle assumes when you declare a function to be deterministic. The database
cannot recognize if the action of the function is indeed deterministic. Its your responsibility as a
developer to make sure that a function abides by the above rules when you declare it
deterministic, otherwise the result of queries involving that function is unpredictable.

Only functions that are DETERMINISTIC are allowed in function-based indexes and in
materialized views.

To declare a function deterministic, you place the DETERMINISTIC keyword after the return
value type in a declaration of the function.
When Oracle Database (10g and above) encounters a call to execute a deterministic function
from within a SQL query, it attempts to use previously cached calculated results when possible
rather than re-executing the function.

Oracle Database will not cache the deterministic function results if the function is called from
inside a PL/SQL block.

When to use deterministic functions

It is a good programming practice to make functions that fall into these categories
DETERMINISTIC8:

Functions used in a WHERE, ORDER BY, or GROUP BY clause

Functions that MAP or ORDER methods of a SQL type
Functions that help determine whether or where a row appears in a result set

Package-Based Cache
Constants and variables - either scalar or PL/SQL collections - that are not defined within any
function or procedure in a package are called package data. Package data declared inside the
package specification is called public package data. Package data declared inside the package
body is called private package data. Package data structures, public and private, are cached
within a single Oracle session or connection.

Major differences between SQL and PL/SQL result cache and Package-Based Cache:
Package data is cached on a per session basis. Both SQL Result Cache and PL/SQL
Function Result Cache are at the database instance level and available for all sessions.
Package variables have no idea about the underlying tables being changed. You have to
manually refresh them when the data changes. Both SQL Result Cache and PL/SQL
Function Result Cache automatically refresh the cache when the underlying table data
changes.

Consider using a package-based cache when:

You are not yet using Oracle Database version 11g or higher otherwise use SQL result
cache or PL/SQL function result cache instead.
The data you wish to cache does not change for the duration of the session.
Your database server has enough memory to support a copy of the cached data for
each session connected to the instance.

Do not use a package-based cache if:

The data you are caching could possibly change during the session.
The data cached requires too much memory per session.
The data cached requires too much memory with large numbers of users.

8
http://docs.oracle.com/cd/E11882_01/appdev.112/e25518/adfns_packages.htm#ADFNS386
Scalar Subquery Cache
The scalar subquery caching feature of the Oracle database can dramatically decrease the
overhead of continuously switching from SQL to PL/SQL when calling PL/SQL functions in a
SQL query. This context switching can be very expensive. Reduction or elimination of this
overhead results in better performance and faster queries.

Definition of a Scalar Subquery

A scalar subquery expression is a subquery that returns exactly one column value from one
row. The value of the scalar subquery expression is the value of the select list item of the
subquery. If the subquery returns 0 rows, then the value of the scalar subquery expression is
NULL. If the subquery returns more than one row then Oracle returns an error.

You can use a scalar subquery expression in most syntax that calls for an expression or
anywhere a literal could have been used. In all cases, a scalar subquery must be enclosed in its
own parentheses. 9

For example:

In the above example, Oracle rewrites the scalar subquery to use bind variables. So, Oracle
would be executing the following for at least as many times as there are unique
DEPARTMENT_ID values in the EMPLOYEES table:

(SELECT d.department_name
FROM hr.departments d
WHERE d.department_id = ?)

The database does not have to execute the scalar subquery for every row in the EMPLOYEES
table if it caches some of the results and reuses them, which is what happens with scalar
subquery caching.

When youre using a scalar subquery, Oracle Database will set up a small in-memory hash table
for the subquery and its results each time it runs the query. Oracle Database will use this hash
table to remember the scalar subquery and the inputs to it and the output from it. The size of the
hash table cache in Oracle Database 10g and 11g is currently 255.10

9
http://docs.oracle.com/cd/E11882_01/server.112/e26088/expressions013.htm
10
http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html
About the Author
Eddie Awad is a senior Oracle Applications developer. He has been developing applications
using Oracle technologies and tools since 1994. Eddie is an Oracle ACE Director and the
creator of OraNA.info, OracleCommunity.net and OraQA.com. Eddie is also the recipient of
Oracle magazine editors' choice award as the Oracle-related blogger of the year (2006).
Subscribe to Eddies blog at awads.net and follow him on Twitter @eddieawad.