The PL/SQL Function Result Cache
The PL/SQL function result cache uses the same infrastructure as the SQL query result cache, and caches the results of the PL/SQL functions in the result cache component of the SGA. Ideal candidates for caching are functions that the database invokes frequently but which depend on information that changes infrequently or never. If you invoke a function with different combinations of parameter values, the database will cache one result for every unique combination of parameter values. The database uses the input parameters of the function as the lookup key. As with the SQL result cache, the database employs a least recently used algorithm to age out cached results. You can optionally specify the database objects that the cached result depends on, and the database will invalidate the cached results when those database objects change.
How the PL/SQL Function Cache Works
The very first time you execute the body of a result-cached PL/SQL function with a set of parameter values, the function will execute. The function will re-execute under the following circumstances:
- When the cached result for the parameter values is invalid because an object specified in the relies_on clause has changed
- When the function bypasses the result cache
- When the cached result for the set of parameter values has aged out because the system needs memory
Creating a Cacheable Function
To make the database cache the results of a PL/SQL function, simply include the result_cache clause in the function definition. You can optionally specify the relies_on clause to make the database invalidate the cache when the database modifies any of the listed tables or views. The following example shows how to create a function that specifies that the database cache its results:
SQL> create or replace function
get_dept_info (dept_id number) return dept_info_record
result_cache relies_on (employees)
is
rec dept_info_record;
begin
select avg(salary), count(*) into rec
from employees
where department_id = dept_id;
return rec;
end get_dept_info;
/
The GET_DEPT_INFO function fetches the number of employees and their average salary from a department that you specify. The result_cache clause ensures that the database saves the results of the function’s execution in the result cache. The optional relies_on clause specifies that the database must invalidate the cached results of this function whenever the EMPLOYEES table changes.
Note: The RELIES ON clause is unnecessary in 11.2 as it automatically tracks dependencies and invalidates the cached results when necessary.
Restrictions
In order for the database to cache its results, a function must satisfy all of these criteria:
- It can’t be a pipelined table function.
- It can’t have any out or in out parameters.
- It is not defined in an anonymous block; it must be a named function.
- It isn’t defined in a module that has invoker’s rights.
- It can’t have any in parameters belong to the LOB type, ref cursor, and collection, object, or record types.
- In addition, the function must not have any side effects or depend on session- specific settings or session-specific application contexts.
The Client Query Result cache
In addition to the SQL result cache and the PL/SQL function result cache, which are server-side caches, Oracle Database 11g also provides a new Oracle Call Interface (OCI) result cache to enable client-side caching of SQL result sets. All OCI applications and drivers, such as JDBC-OCI, ODP.NET, OCCI, Pro*C/C++, Pro*COBOL, and ODBC, can take advantage of the client result cache.
The OCI result cache, which is transparent to OCI applications, keeps the result data set consistent with any changes in the session attributes or in the database itself. OCI client caching leads to a tremendous improvement in query performance for frequently repeated statements because the results are cached on the client itself, thus avoiding the expensive round trip to the server. Because you use fewer server resources as a result, this feature also enhances server scalability. In addition to a lower server CPU usage, client result caching also relieves the server of additional I/O burden to process frequently repeated queries.
The OCI result cache, which is on a per-process basis among multiple client sessions, can use the same cached result sets. The database automatically refreshes the result sets in the cache and manages memory allocation to the cache. If, during the round trips the OCI process makes to the server, any database changes affect the result set, the database automatically invalidates the cached result sets. That is, the database keeps the client result set transparently consistent with changes on the server. The big difference between the server-side result cache and the OCI client result cache, of course, is that the OCI result cache is located on the client and, therefore, doesn’t make any use of the server SGA.
While the server result cache is enabled by default, the client result cache is not. The server result cache and the client result cache work independent of each other. You can enable the client result cache even if you decide to disable the server result cache. Note that while the client result cache caches only the results of top-level SQL queries, the server result cache can also cache query fragments.
Client result caching is especially useful when applications produce repeatable or small result sets, which tend to be static over time. Frequently executed queries are also candidates for caching on the client. Lookup tables are particularly attractive candidates for client caching.
Enabling and Disabling the Client Result Cache As with the server-side result cache, you set the result_cache_mode initialization parameter to control whether the database caches the query results on the client.
Here’s how the result_cache_mode initialization parameter settings affect client-side result caching: If you set the result_cache_mode parameter to manual, you must annotate a query with the result_cache hint for the database to store it in the client cache, as shown here:
SQL> select /*+ result_cache */ deptno, avg(sal)
from emp
group by deptno;
If you set the result_cache_mode parameter to force, the database will store all SQL query results in the client cache whenever it’s possible to do so. If you don’t want the database to use the client cache for a query, you must specify the /*+ no_result_cache */ hint in the query, as shown here:
SQL> select /*+ no_result_cache */ deptno, avg(sal)
from emp
group by deptno;
You can set the result_cache_mode parameter with the alter system or alter session statement. The no_result_cache hint overrides the force setting of the result_cache_mode parameter, which would cause result caching behavior without the hint.
How Client Result Caching Works
When you specify either the result_cache or the no result_cache hint, you must add the hint to the SQL text you pass to the OCIStmtPrepare() and the OCIStmtPrepare2() calls. Managing the Client Result Cache You manage the client result cache by setting the following initialization parameters:
- client_result_cache_size:This parameter determines the maximum size of the client per-process result set cache (in bytes). The setting of the parameter also determines if the cache is enabled. By setting this parameter to its default value of zero, you can disable the client result cache. By default, the database allocates every OCI client process the maximum size specified by this parameter. You can override this parameter with the server-side configuration parameter oci_result_ cache_max_size. If you disable client result caching on the server itself, the client result cache will remain disabled, even if you set the client_ result_cache_size parameter to a positive value on the client. The following query shows the current value of the client_result_cache_size parameter:
SQL> show parameter client_result_cache_size
NAME TYPE VALUE
--------------------------- ----------- -----
client_result_cache_size big integer 0
As this parameter is static, you must restart the database to affect a change in the maximum size of the client result cache.
- client_result_cache_lag:This parameter determines the lag time for the client result cache. If you set a low value for this parameter, it results in more round trips to the database from the OCI client library to keep the client result cache in sync with the database. If your OCI application accesses the database only infrequently, you can set this parameter to a low value.
You can also use a client configuration file, which overrides the parameters you set in the server initialization parameter file. You can use the sqlnet.ora file to specify the parameter values on the client side.
When you use the client configuration file, you can specify the following three parameters:
- oci_result_cache_max_size enables you to set the maximum size of the query cache for a process (in bytes). This parameter overrides the value you set for the client_result_cache_lag_size initialization parameter on the server.
- oci_result_cache_max_rset_size enables you to set the maximum size (in bytes) of a single query result in the query cache for a process.
- oci_result_cache_max_rset_rows enables you to set the maximum size of a query result set (in rows) for a process.
You can specify the result_cache and the no_result_cache hints in OCI applications, as with the SQL statements for the SQL query cache. However, the OCIStmtExecute() mode settings override the SQL hints.
Monitoring the Client Result Cache
The CLIENT_RESULT_CACHE_STATS$ view shows the client result cache settings and the cache usage statistics. The view includes information such as the number of results cached on the client, the number of cache hits, and the number of invalidated result sets.
Restrictions
You can’t cache queries that include the following objects on the OCI client, even though you may cache them in the server-side result cache:
- Views
- Remote objects
- Complex types in the select list
- Flashback queries
- Queries that include PL/SQL functions
- Queries that reference VPD polices on the tables
参 考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》 http://www.oracle-base.com/articles/11g/query-result-cache-11gr1.php
http://www.oracle-base.com/articles/11g/cross-session-plsql-function-result-cache-11gr1.php
本文原创，转载请注明出处、作者
如有错误，欢迎指正