Quantcast
Channel: Gokhan Atil – Gokhan Atil’s Blog
Viewing all articles
Browse latest Browse all 108

When is a Table Populated into the In-Memory Column Store?

$
0
0

I was playing with in-memory feature of Oracle 12c, and wondered when a table is loaded/populated into in-memory buffer (of course I’m talking about a table which is enabled for in-memory). In “the Oracle Database In-Memory blog”, it says Oracle typically populates the table after it has been accessed for the first time. It’s possible to check V$IM_SEGMENTS to see the memory segments of in-memory tables, so we can easily see when the table is populated into the memory. Let’s create a test table and fill it with some data:

CREATE TABLE gokhan.test INMEMORY AS SELECT * FROM dba_objects;

Now let’s access the data:

SELECT COUNT (*) FROM gokhan.test WHERE object_type = 'PACKAGE BODY';

  COUNT(*)
----------
      1245
1 row selected.

I checked again the V$IM_SEGMENTS:

SELECT segment_name, inmemory_size, bytes FROM V$IM_SEGMENTS;

SEGMENT_NAME         INMEMORY_SIZE      BYTES
-------------------- ------------- ----------
TEST                       4325376   13631488
                                                                                
1 row selected.

Everything is as expected. What happens if you update (or delete) the all rows? I thought Oracle should access the all rows so our table should be populated into the in-memory. I dropped and recreate the table, check the execution plan and see that it’ll again do “TABLE ACCESS INMEMORY FULL”, then run the update and checked the V$IM_SEGMENTS:

UPDATE gokhan.test SET OBJECT_TYPE = 'TESTING';
90959 rows updated.

COMMIT;
Commit complete.

SELECT segment_name, inmemory_size, bytes FROM V$IM_SEGMENTS;
no rows selected.

As you see the table is not populated into the in-memory! If the in-memory option were not enabled for the table, all these queries would do “TABLE ACCESS FULL”. So it seems some TABLE ACCESS FULL operations cause the table is populated into the in-memory but some does not.

By the way, execution plan of the SELECT/UPDATE queries show that optimize will do “TABLE ACCESS INMEMORY FULL” although the table is not populated into the in-memory! So in execution plans you always see TABLE ACCESS INMEMORY FULL instead of TABLE ACCESS FULL if the table is enabled for in-memory. It doesn’t matter if the table is really in in-memory buffer.

You also need to be careful about indexes. If your table has some indexes, and your queries always use these indexes, then this table won’t be populated into the memory until a TABLE ACCESS FULL operation is done (at least it won’t get populated into in-memory using INDEX SCANS. Funny thing is creating an index may be also not enough to the table is populated into the in-memory (!?):

CREATE INDEX gokhan.test_ot ON gokhan.test (object_type);
Index created.
   
SELECT segment_name, inmemory_size, bytes FROM V$IM_SEGMENTS;
no rows selected.


Viewing all articles
Browse latest Browse all 108

Trending Articles