Oracle Magazine - September/October 2007 - Marcelo Machado

ASK TOM
4 begin
5 for x in
6 (select /*+ result_cache */
7 owner,
8 object_type,
9 count(*) cnt
10 from t
11 group by owner, object_type
12 order by owner, object_type )
13 loop
14 -- do_something
15 null;
16 end loop;
17 end;
18 /
Procedure created.
SQL> set timing on
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.10
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
SQL> set timing off
Note how the first execution took
about 0.1 second, because the answer
was assembled for the first execution,
but that the subsequent executions were
blindingly fast—sometimes so fast that
they appear instantaneous.
The nice thing about this is that the
cache is invalidated and refreshed by
the database—and the process is completely
transparent to the application.
The application need not worry about
“stale” or invalid results. For example,
if I update a single row, thus changing
the results—
SQL> update t
2 set owner = lower(owner)
3 where rownum = 1;
1 row updated.
SQL> commit;
Commit complete.
—I observe the following behavior:
SQL> set timing on
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.10
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
SQL> exec my_function
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
SQL> set timing off
Note that the first execution after
the UPDATE went back up to about 0.1
second of execution time because it had
to build the new answer. The subsequent
executions benefit from this work
and appear instantaneous.
I’m sure that if you sit back and
ponder your own applications, you
will be able to think of more than one
place where the server results cache
feature will come in handy. It provides
many of the benefits of some materialized
views, but without the setup and
administrative overhead associated
with them.
BUT WAIT—THERE’S MORE. . . .
As they say on late night television,
“If you thought that was really good,
wait till you see this!” Oracle Database
11g has a new PL/SQL function results
cache as well. Whereas the aforementioned
server results cache is about
caching SQL result sets, this extension
of the server results cache feature caches
the results of PL/SQL function and procedure
calls.
In the past, if you called a PL/SQL
function 1,000 times and each function
call consumed 1 second, the 1,000
calls would take 1,000 seconds. With
this new function results cache feature,
depending on the inputs to the function
and whether the data underlying
the function changes, 1,000 function
calls could take about 1 second, total. A
small example will be useful: I’ll create
86 SEPTEMBER/OCTOBER 2007 ORACLE.COM/ORACLEMAGAZINE
two functions, identical except in name
and compiler parameter options. They
will both access the previously created
table T:
SQL> create or replace
2 function not_cached
3 ( p_owner in varchar2 )
4 return number
5 as
6 l_cnt number;
7 begin
8 select count(*)
9 into l_cnt
10 from t
11 where owner = p_owner;
12 dbms_lock.sleep(1);
13 return l_cnt;
14 end;
15 /
Function created.
SQL> create or replace
2 function cached
3 ( p_owner in varchar2 )
4 return number
5 result_cache
6 relies_on(T)
7 as
8 l_cnt number;
9 begin
10 select count(*)
11 into l_cnt
12 from t
13 where owner = p_owner;
14 dbms_lock.sleep(1);
15 return l_cnt;
16 end;
17 /
Function created.
The only difference in the functions
besides the names are the compiler
parameters RESULT_CACHE and
RELIES_ON. The RESULT_CACHE
directive tells Oracle Database that you
would like the answers from this function
to be saved, so that if someone
invokes this function again with the
same inputs, the code should not
actually be executed but, rather, that
person should just receive the already
known answer. The RELIES_ON clause
tells the database when to invalidate
this function result cache value—in