Oracle Scratchpad

August 15, 2014

In-memory limitation

Filed under: 12c,in-memory,Oracle — Jonathan Lewis @ 8:51 pm GMT Aug 15,2014

I’ve been struggling to find time to have any interaction with the Oracle community for the last couple of months – partly due to workload, partly due to family matters and (okay, I’ll admit it) I really did have a few days’ holiday this month. So making my comeback with a bang – here’s a quick comment about the in-memory feature, and how it didn’t quite live up to my expectation; but it’s also a comment about assumptions, tests, and inventiveness.

One of the manuals tells us that the optimizer can combine the in-memory columnar storage mechanism with the “traditional” row store mechanisms – unfortunately it turned out that this didn’t mean quite what I had hoped; I had expected too much of the first release. Here’s a quick demo of what doesn’t happen, what I wanted to happen, and how I made it happen, starting with a simple definition (note – this is running 12.1.02 and the inmemory_size parameter has been set to enable the feature):

create table t1 nologging
select	*
from	all_objects
where	rownum <= 50000

alter table t1 inmemory
no inmemory (object_id, object_name)
inmemory memcompress for query low (object_type)
-- all other columns implicitly inmemory default

insert into t1 select * from t1;

insert into t1 select * from t1;

insert into t1 select * from t1;

	dbms_stats.gather_table_stats(user, 't1', method_opt=>'for all columns size 1');

rem	Needs select on v$_im_column_level granted

where	owner = user
and	table_name = 'T1'
order by

explain plan for
	last_ddl_time, created
where	t1.created > trunc(sysdate)
and	t1.object_type = 'TABLE'
and	t1.subobject_name is not null

select * from table(dbms_xplan.display);

All I’ve done at this point is create a table with most of its columns in-memory and a couple excluded from the columnar store. This is modelling a table with a very large number of columns where most queries are targeted at a relatively small subset of the data; I don’t want to have to store EVERY column in-memory in order to get the benefit of the feature, so I’m prepared to trade lower memory usage in general against slower performance for some queries. The query against v$im_column_level shows me which columns are in-memory, and how they are stored. The call to explain plan and dbms_xplan then shows that a query involving only columns that are declared in-memory could take advantage of the feature. Here’s the resulting execution plan:

| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT           |      |     1 |    27 |    73   (9)| 00:00:01 |
|*  1 |  TABLE ACCESS INMEMORY FULL| T1   |     1 |    27 |    73   (9)| 00:00:01 |

Predicate Information (identified by operation id):
   1 - inmemory("T1"."SUBOBJECT_NAME" IS NOT NULL AND

Note that the table access full includes the inmemory keyword; and the predicate section shows the predicates that have taken advantage of in-memory columns. The question is – what happens if I add the object_id column (which I’ve declared as no inmemory) to the select list.  Here’s the resulting plan:

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |     1 |    32 |  1818   (1)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T1   |     1 |    32 |  1818   (1)| 00:00:01 |

Predicate Information (identified by operation id):


There’s simply no sign of an in-memory strategy – it’s just a normal full tablescan (and I didn’t stop with execution plans, of course, I ran other tests with tracing, snapshots of dynamic performance views etc. to check what was actually happening at run-time).

In principle there’s no reason why Oracle couldn’t use the in-memory columns that appear in the where clause to determine the rowids of the rows that I need to select and then visit the rows by rowid but (at present) the optimizer doesn’t generate a plan to do that. There’s no reason, though, why we couldn’t try to manipulate the SQL to produce exactly that effect:

explain plan for
        /*+ no_eliminate_join(t1b) no_eliminate_join(t1a) */
        t1b.object_id, t1b.last_ddl_time, t1b.created
        t1 t1a, t1 t1b
where   t1a.created > trunc(sysdate)
and     t1a.object_type = 'TABLE'
and     t1a.subobject_name is not null
and     t1b.rowid = t1a.rowid

select * from table(dbms_xplan.display);

| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |      |     1 |    64 |    74   (9)| 00:00:01 |
|   1 |  NESTED LOOPS               |      |     1 |    64 |    74   (9)| 00:00:01 |
|*  2 |   TABLE ACCESS INMEMORY FULL| T1   |     1 |    31 |    73   (9)| 00:00:01 |
|   3 |   TABLE ACCESS BY USER ROWID| T1   |     1 |    33 |     1   (0)| 00:00:01 |

Predicate Information (identified by operation id):
   2 - inmemory("T1A"."SUBOBJECT_NAME" IS NOT NULL AND

I’ve joined the table to itself by rowid, hinting to stop the optimizer from getting too clever and eliminating the join. In the join I’ve ensured that one reference to the table can be met completely from the in-memory columns, isolating the no inmemory columns to the second reference to the table. It is significant that the in-memory tablescan is vastly lower in cost than the traditional tablescan – and there will be occasions when this difference (combined with the knowledge that the target is a relatively small number of rows) means that this is a very sensible strategy. Note – the hints I’ve used happen to be sufficient to demonstrate method but I’d be much more thorough in a production system (possibly using an SQL baseline to fix the execution plan).

Of course, this method is just another example of the “visit a table twice to improve the efficiency” strategy that I wrote about a long time ago; and it’s this particular variant of the strategy that allows you to think of the in-memory columnar option as an implementation of OLTP bitmap indexes.


  1. Hi Jonathan,
    Very nice information as always…


    Comment by Wellington Prado — August 15, 2014 @ 9:07 pm GMT Aug 15,2014 | Reply

  2. Interesting and useful, as usual. Thanks for that, Jonathan. Yet …

    What is that 12cR2 you are referring to in this post and have referred to previously as well? Is there a for-the-public-not-downloadable, super secret release 2 of (the 12c version of) our beloved RDBMS? A quick look to the Downloads section of the Oracle web says the 12.1 is still the newest.

    Comment by Peter Hrasko — August 15, 2014 @ 9:58 pm GMT Aug 15,2014 | Reply

    • Peter,

      Automatic finger trouble – too much typing 11gR2. It’s
      I’ll correct it as soon as WordPress stops showing me a silly screen when I try to edit the page.

      Comment by Jonathan Lewis — August 15, 2014 @ 10:04 pm GMT Aug 15,2014 | Reply

  3. Hi Jonathan,
    Very interesting. So that means that the in-memory column store is able to return the rowid, but cannot do an ‘access by rowid’. Do you know where the rowid is stored or mapped? IMCU header? Does the analogy with bitmap index applies so far?

    Comment by @FranckPachot — August 16, 2014 @ 10:10 am GMT Aug 16,2014 | Reply

    • Franck,

      It’s a good question, and I don’t have an answer yet – I know only that the rowid can be derived somehow, and since this isn’t required for Exadata HCC we won’t get much of a clue from looking at an on-disk CU.

      It seems likely that Oracle uses the arithmetic of relative position to derive a rowid – but there are several strategies that it might choose to do this; using the bitmap strategy (i.e. Hakan factor) and padding each compressed column to allow for the “missing” rows across all the blocks in the CU would probably be quite space efficient – it might be worth testing whether the memory used by an in-memory table changed at all if you constructed an extreme case with and without using “minimize_records_per_block”.

      I would be a little surprised if Oracle kept the actual rowids as a (in-memory, compressed) pseudo-column and then simply synchronised rowid with row content by position – but it’s another possibility to investigate.

      Comment by Jonathan Lewis — August 16, 2014 @ 6:24 pm GMT Aug 16,2014 | Reply

  4. Another even simpler limitation of the in-memory-option is that it is only supported for heap-organized tables at the moment, not for index-organized ones.
    But it’s only V1.0, we have to wait until it gets grown-up I would suppose and see what further it will be able to do then.

    Comment by Matthias Rogel — August 17, 2014 @ 11:20 am GMT Aug 17,2014 | Reply

    • Matthias,

      But that limitation – along with several others – is documented. I’m usually more interested in finding out the things that don’t work that you might think ought to work.

      Comment by Jonathan Lewis — August 17, 2014 @ 9:12 pm GMT Aug 17,2014 | Reply

  5. […] piece is the name given to a new feature in, and since I’ve recently blogged about a limitation of the in-memory option I thought I’d pick this feature as the next obvious thing to blog about. This is a bit of a […]

    Pingback by In-memory Aggregation | Oracle Scratchpad — August 24, 2014 @ 8:05 pm GMT Aug 24,2014 | Reply

  6. […] of the subsequent observations. The data is (nearly) the same as the data I generated for my previous article on the in-memory database (and I’m running, of […]

    Pingback by In-memory Consistency | Oracle Scratchpad — August 27, 2014 @ 7:00 pm GMT Aug 27,2014 | 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

The Rubric Theme. Blog at


Get every new post delivered to your Inbox.

Join 4,521 other followers