Oracle Scratchpad

September 22, 2015

Result Cache

Filed under: 12c,Bugs,Infrastructure,Oracle,Performance — Jonathan Lewis @ 10:11 am BST Sep 22,2015

Yesterday I thought I’d spend half an hour before breakfast creating a little demonstration of a feature; some time about midnight I felt it was time to stop because I’d spent enough time chasing around a couple of bugs that produced wrong results in a variety of ways. Today’s short post is just little warning: be VERY careful what you do with the PL/SQL result cache – if you use the results of database queries in the cache you may end up with inconsistent results in your application. Here’s one very simple example of what can go wrong, starting with a little script:

alter system flush shared_pool;

truncate table gtt1;
drop table gtt1;
create global temporary table gtt1 (n1 number)
on commit preserve rows

insert into gtt1 values(1);

execute dbms_stats.gather_table_stats(user,'gtt1');

create or replace function f_cache
return number 
-- relies_on (gtt1)
        m_ret number;
        select  max(n1)
        into    f_cache.m_ret
        from    gtt1

        return f_cache.m_ret;

execute dbms_output.put_line(f_cache)

Here’s the output from a session that’s just connected and run this script (the table already existed from an earlier run):

SQL> @temp

System altered.

Table truncated.

Table dropped.

Table created.

1 row created.

Commit complete.

PL/SQL procedure successfully completed.

Function created.


PL/SQL procedure successfully completed.


Let’s call this session A, and I’m going to connect with another session which I’ll call session B. The following extracts are cut-and-pastes as I alternate between sessions:

Session B:

SQL> execute dbms_output.put_line(f_cache);

PL/SQL procedure successfully completed.

SQL> insert into gtt1 values(0);

1 row created.

SQL> execute dbms_output.put_line(f_cache);

PL/SQL procedure successfully completed.

Session B has just seen the data inserted into a global temporary table by session A; but after inserting a row into the table it now sees what it perceives to be the correct answer.

Session A:

SQL> truncate table gtt1;

Table truncated.

SQL> execute dbms_output.put_line(f_cache);

PL/SQL procedure successfully completed.

Despite truncating the table, session A still sees the data which has been eliminated unrecoverably.

Session B (where I hadn’t yet committed):

SQL> commit;

Commit complete.


Session A (where I’ve done nothing new):

SQL> execute dbms_output.put_line(f_cache);

PL/SQL procedure successfully completed.


The row has finally “disappeared” because session B committed.

Session B (where I haven’t done anything since committing):

SQL> execute dbms_output.put_line(f_cache);

PL/SQL procedure successfully completed.


Session B no longer sees the data because it’s now seeing what session A has just seen.


This is just one of several ways I managed to get surprising inconsistencies when using the (cross-session) PL/SQL Result Cache. Oracle (in 12c) is supposed to know what the cache relies on and react accordingly, but it doesn’t manage to do it properly (even if you include the relies_on clause) – if you query the database in your PL/SQL you may find strange things happen.

The most important point to note in this example is that a session that wasn’t necessarily doing anything wrong got the wrong results because of the actions of another session that Oracle should have protected it from.

The good thing about this is example that it’s documented (sort of) – as it says in the manual: “to be result cached … does not reference … temporary tables ..”. So that should warn people off copying my example; on the other hand the problem I’m seeing arises because Oracle seems to be trying to use the result cache when the manuals suggests it shouldn’t be.


Do not mix the pl/sql result cache with database queries. The cache is public but (unlike the buffer cache) it is not guaranteed to give you read-consistency.

If you think this was an unrealistic example and you don’t need to worry about it – I’ll post a couple more examples in the next couple of weeks. They’ll be slightly special cases again, but I find the Oracle world is full of special cases.


This behaviour is now visible on MoS as “Bug 21907155 : PL/SQL RC FN SHOWS ONE SESSION THE CONTENTS OF ANOTHER SESSION’S GTT”


  1. Jonathan,
    I wrote about a couple nonintuitive things too:
    1. Different results cached and fetched within one function call:
    2. Different behaviour for different objects of runtime dependency tracking:
    3. Strange invalidations:

    btw, I still don’t know how and when oracle invalidates result_cache…

    Comment by Sayan Malakshinov — September 22, 2015 @ 10:38 am BST Sep 22,2015 | Reply

  2. I found similar issues when using the function result cache in 11g, although if used carefully it can be very effective. I listed the situations where the cache is invalidated (and where it is not) in an older presentation here:

    Comment by Jeffrey Kemp — September 22, 2015 @ 2:05 pm BST Sep 22,2015 | Reply

  3. […] on from my earlier posting of problems with temporary table and the PL/SQL result cache (a combination which the manuals warn you against) here’s another problem – again, to a […]

    Pingback by Result Cache 2 | Oracle Scratchpad — September 28, 2015 @ 8:50 am BST Sep 28,2015 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at