Oracle in-memory concept has been introduced in oracle 12c. This feature enables tables, partitions, materialized views be stored in memory using column format, which delivers fast SQL processing for the Analytical purpose.

To understand Database In-Memory feature and its benefits we first need to understand the unique “dual format” architecture that enables Oracle Database tables to be simultaneously represented on disk and in memory, using a traditional row format and a new in-memory column format.

Row Format – Oracle has traditionally stored data in row format where each new record is represented as a new row in a table having multiple columns with each column representing a different attribute about that record. This format is ideal for OLTP Env. as it allows quick access to all the columns in a record since all the columns of the record are kept intact in-memory and on storage.This is ideal for processing DMLs (Insert, Update, Delete)

Column Format – A column format database stores each of the attributes of a record in a separate column-structure. So obviously this is good for an OLAP Env, as it allows faster data retrieval when a large portion of data is selected but only for a few columns.

Oracle Database In-Memory feature enables data to be simultaneously populated in memory in both a row format (in the buffer cache) and a
new in-memory column format. The In-Memory Column Store(IMCS) is a static pool in the Oracle System Global Area (SGA) associated with the
Oracle Database. It stores copies of objects in the memory in a columnar format. The IMCS does not replace the buffer cache but supplements it so
that both the memory areas can store data in different formats.The Oracle Database query optimizer is fully aware of the column format and thus it
automatically routes analytic queries to the column format and OLTP operations to the row format, ensuring outstanding performance and complete data consistency for all workloads without any application changes.
You can choose to store specific groups of columns, whole tables, materialized views or table partitions in the store. Alternatively,
you can enable IM column store at the tablespace level, so all tables and materialized views in the tablespace are automatically enabled for the IM column store.

Reference –

NOTE – The compatible parameter should be set to or later

How to check whether inmemory is enabled or not:

Here inmemory_size is set to ZERO, shows that in-memory is not enabled in databases.

How to enable the in-memory feature in DB:

You may have to resize the SGA, after allocating space to inmemory . Now in-memory feature is enabled in databases. Now let’s enable in-memory for a table.(DBACLASS.TEST2)

Enable in-memory for  a table

Now check if it is populated in im_segment or not.

After enabling in-memory,we need to query that table once, to load in memory.

Now check again:

Now the im_segment table is populated.

Now check the explain plan:

Background process:

The background process imco (IN MEMORY COORDINATOR)  is responsible for loading the in-memory enabled objects to memory

Enable in-memory with PRIORITY CRITICAL

With this option, the respective tables will be loaded to memory upon database startup.

Enable in-memory for a tablespace:

If enabled at tablespace level, all the tables will enable for IM column store.

Disable in-memory for the table:


V$INMEMORY_AREA stores the usage of inmemory area.

1MB pool used to store the actual column-formatted data populated into memory
64K pool used to store metadata about the objects that are populated into the IM column store