Why IMCS exists (and when to use it)

IMCS keeps a columnar copy of your hot data in memory—alongside Tibero’s traditional row store—so filters and analytics scan far fewer bytes. This helps mixed OLTP/OLAP environments without changing application logic.

Key effects: column‑wise storage, column compression, and IMCU pruning (skipping memory chunks that don’t match your predicates).

📌 IMCS Introduction: https://docs.tibero.com/tibero/en/topics/administration/performance/introduction-to-imcs

The In‑Memory Area and how it’s sized

MCS lives in the In‑Memory Area, allocated from shared memory at database startup and fixed until the next startup. You size it with the INMEMORY_SIZE parameter.

• INMEMORY_SIZE enables/disables IMCS (default 0 = off).
• Minimum is 100 MB; changes aren’t dynamic—restart required.

📌 IMCS Configuration: https://docs.tibero.com/tibero/en/topics/administration/performance/imcs-configuration

In TAC clusters, every node must use the same INMEMORY_SIZE.

📌 In-Memory DataBase Reference: https://docs.tibero.com/tibero/en/topics/administration/performance/in-memory-database-reference

Inside IMCS: IMCU, SMU, and SIMD

IMCU (In‑Memory Compression Unit): the storage unit for columnar data (size 1 MB). Each IMCU contains one or more CUs (per‑column blocks) with dictionary‑encoded values for compact scans.

SMU (Snapshot Metadata Unit): metadata and transaction journal per IMCU.

Data pruning: IMCUs store min/max per column so the engine can skip irrelevant IMCUs.

SIMD vector processing: evaluates WHERE‑clause comparisons on multiple values per CPU instruction (supports >, >=, =, <, <=, AND).

Enabling IMCS (and changing it safely)

1. Set INMEMORY_SIZE (≥ 100M) in the tip file.

2. Restart the database (required for enable/disable or size change).

Choosing what goes In‑Memory

IMCS population is separate from enabling the area. You mark objects and Tibero populates them either on demand or by priority.

• Where to set it: tablespace (DEFAULT_INMEMORY), table (INMEMORY / NO INMEMORY), partition/subpartition; you can also mark specific columns not to populate.
• Priority options: NONE (on‑demand), LOW, MEDIUM, HIGH, CRITICAL (background population in priority order; stops when the area is full).
• Eligibility note: segments under 64 KB aren’t populated even if marked.

High availability + IMCS in TAC

• Per‑node memory: each TAC instance has its own IMCS area.
• Distribution (DISTRIBUTE): by default Tibero distributes In‑Memory objects across all nodes; AUTO is the default (other modes like By Rowid Range/Partition/Subpartition are listed as not supported).
• Duplication (DUPLICATE): control how many copies exist across nodes (NO DUPLICATE default; DUPLICATE ALL stores a copy on every node; single‑copy DUPLICATE is marked not supported).
• Parallel scans: because data is distributed, IMCS scans run in parallel across nodes, with DOP influenced by the node count.

📌 High Availability and IMCS: https://docs.tibero.com/tibero/en/topics/administration/performance/high-availability-and-imcs

Observability: views you’ll actually use

• V$IM_SEGMENTS — what’s populated, size, POPUATE_STATUS, bytes not populated, DISTRIBUTE/DUPLICATE/COMPRESSION options in effect.
• V$SIM_COLUMN_LEVEL — column‑level compression / “No Inmemory” status.

These are the go‑to views to confirm whether objects are populated, how large they are in memory, and whether your distribution/duplication policies are applied as expected.

A practical rollout plan

1. Capacity: decide INMEMORY_SIZE (≥ 100 MB) and restart; in TAC, make the value equal on all nodes.
2. Scope: start with the most scan‑heavy tables or partitions; avoid very small segments (< 64 KB).
3. Population policy: use INMEMORY_PROPERTY for must‑be‑warm objects; leave others NONE (on‑demand).
4. HA strategy: keep DISTRIBUTE=AUTO initially; consider DUPLICATE ALL for critical datasets that must be resident on every node.
5. Verify: query V$IM_SEGMENTS to check POPULATE_STATUS, sizes, and distribution/duplication flags.

What this means for teams evaluating Tibero as an Oracle alternative

IMCS is a built‑in capability of the Tibero Database (DBMS). It adds columnar, compressed, and prunable in‑memory copies—plus cluster‑aware distribution and parallel scans—without changing row‑store behavior. For organizations seeking Oracle compatibility and a credible Oracle alternative, IMCS provides a doc‑backed path to accelerate analytics and mixed workloads within Tibero’s architecture.

Quick reference (Docs)

• Introduction to IMCS — concepts, IMCU/SMU, pruning, SIMD.
• IMCS Configuration — enabling, priority‑based vs on‑demand population; DDL examples.
• High Availability & IMCS — TAC behavior, DISTRIBUTE/DUPLICATE, parallelism.
• In‑Memory Database Reference — INMEMORY_SIZE rules, dynamic performance views.

If you want, I can follow up with a runnable checklist (tbSQL snippets) that sets priorities, verifies V$IM_SEGMENTS and demonstrates DUPLICATE ALL / AUTO distribution—again strictly from the Docs.

* Sources: Tibero Docs(https://docs.tibero.com/tibero/en)