Back to Blog
Oracle Database

Learn Oracle database 26ai In-Memory Column Store Internals: IMCU, SMU, and Compression Explained

Explore Oracle In-Memory Column Store internals including IMCU, SMU, and compression units with DBA-level insights and performance optimization techniques.

March 30, 2026
3 min read
Oracle Database
0 views0 readers0 comments
T

by Thiwanka SenarathnaMarch 30, 2026

Why Understanding In-Memory Internals Matters

Are you using Oracle In-Memory but not seeing expected performance improvements?

Most DBAs enable In-Memory, but do not understand how data is actually stored internally. Without this knowledge, it is difficult to optimize performance.

Oracle In-Memory Column Store internals define how data is:

  • Stored in memory

  • Compressed

  • Scanned efficiently

Understanding these structures allows you to design better systems and troubleshoot performance issues.

If you are new to this topic, read:

https://oracledbexpert.com/blog/oracle-database-in-memory-architecture-overview-dual-format-im-column-store-and-internal-design

What Happens When a Table Is Marked INMEMORY

When you execute:

ALTER TABLE sales INMEMORY;

Oracle does not immediately load the data. Instead:

  1. The table is marked for In-Memory

  2. The IMCO process schedules population

  3. Worker processes load data into IM Column Store

Core Internal Structures

Oracle organizes data in memory using several optimized structures.

In-Memory Compression Units (IMCU)

IMCU is the main storage unit inside the In-Memory Column Store.

Key Characteristics

  • Stores data in columnar format

  • Contains thousands of rows per unit

  • Uses compression for efficiency

  • Optimized for scanning

Logical View

Instead of storing:

Row format:
[Row1: col1, col2, col3]
[Row2: col1, col2, col3]

IMCU stores:

Column format:
col1 → [values]
col2 → [values]
col3 → [values]

Why IMCU Is Important

  • Reduces memory usage

  • Improves scan speed

  • Enables vector processing

Snapshot Metadata Units (SMU)

SMU tracks changes made to data after it is loaded into memory.

Purpose

  • Maintains read consistency

  • Tracks updated rows

  • Ensures queries see correct data

Example Scenario

  1. Data loaded into IMCU

  2. Row is updated

  3. Change stored in SMU

  4. Query merges IMCU + SMU

Key Benefit

No need to reload entire IMCU for small changes.

In-Memory Expression Units (IMEU)

IMEU stores frequently used expressions in memory.

Example

SELECT price * quantity AS total_value
FROM sales;

Instead of calculating every time:

  • Oracle stores the result in IMEU

  • Future queries reuse it

Enable Expression Capture

EXEC DBMS_INMEMORY_ADMIN.IME_CAPTURE_EXPRESSIONS;

Benefit

  • Reduces CPU usage

  • Improves query performance

In-Memory Compression

Compression is a key feature of Oracle In-Memory.

Compression Levels

ALTER TABLE sales INMEMORY MEMCOMPRESS FOR QUERY LOW;

Types

  • FOR QUERY LOW → faster access

  • FOR QUERY HIGH → more compression

  • FOR CAPACITY LOW → save memory

  • FOR CAPACITY HIGH → maximum compression

Trade-Off

Type

Speed

Compression

QUERY LOW

High

Medium

CAPACITY HIGH

Lower

High

How Oracle Scans Data in Memory

Oracle does not use traditional row-by-row scanning.

Instead, it uses:

Column Pruning

Only required columns are accessed.

Predicate Pushdown

Filtering happens inside the scan.

Example

SELECT SUM(amount_sold)
FROM sales
WHERE region_id = 10;

Execution:

  • Scan only amount_sold and region_id

  • Apply filter during scan

  • Aggregate in memory

Population and Repopulation

Initial Population

Data is loaded into IMCU by background processes.

Repopulation

When data changes:

  • Only affected portions are updated

  • SMU tracks changes

  • IMCU updated later

Monitoring In-Memory Structures

Check In-Memory Segments

SELECT segment_name, bytes, inmemory_size
FROM v$im_segments;

Check Population Status

SELECT segment_name, populate_status
FROM v$im_segments;

Check Compression

SELECT segment_name, inmemory_compression
FROM v$im_segments;

Common Mistakes

Overloading Memory

Allocating too many tables:

ALTER TABLE large_table INMEMORY;

Without sizing properly causes eviction issues.

Ignoring Compression

Using default settings without tuning leads to inefficiency.

Not Monitoring Population

Tables may not be fully populated in memory.

Best Practices

  • Use INMEMORY selectively

  • Choose correct compression level

  • Monitor IMCU population

  • Use IM expressions for repeated calculations

  • Analyze memory usage regularly

Next Article

In-Memory Process Architecture: IMCO and Worker Processes Explained

Discussion

Loading comments...