Oracle In-Memory Column Store: Eviction Predictability Limits for Mixed INMEMORY_PRIORITY Workloads

Direct answer

Do not rely on INMEMORY_PRIORITY for residency guarantees. Treat it as population order only. Under a fixed INMEMORY_SIZE, design for capacity isolation: size the store so the CRITICAL working set fits with headroom, and treat NONE segments as opportunistic cache that may be evicted during memory pressure. If a NONE segment is evicted, accept the latency penalty; if a CRITICAL segment is evicted, the sizing or admission control is wrong, not the priority setting.

Confirmed behavior versus limits

Confirmed: INMEMORY_PRIORITY controls the order in which segments are populated after startup or after an ALTER TABLE ... INMEMORY operation. It does not pin a segment in memory. Oracle does not publish the internal eviction score, and V$IM_SEGMENTS or V$IM_SEGMENT_STAT report population status and bytes, not eviction scores or memory-pressure indicators. Changing priority on an already populated segment does not trigger an immediate reload; the new setting applies only after the segment leaves memory and is repopulated.

Unverified: any exact percentage split between CRITICAL and NONE segments, and any documented difference in eviction logic between Oracle Database 19c and later releases. Public notes describe consistent priority semantics across recent releases, but patch-level differences are not ruled out.

Sizing and workload pattern

1. Measure the in-memory footprint of all CRITICAL segments using V$IM_SEGMENTS after full population.
2. Set INMEMORY_SIZE so CRITICAL segments occupy no more than roughly two-thirds of the store, leaving the remainder for NONE segments. Treat this as a starting heuristic, not a guarantee.
3. Route ad-hoc analytic queries to NONE-priority tables and monitor eviction under peak load.
4. If CRITICAL segments are evicted, reduce the NONE workload, increase INMEMORY_SIZE, or move the segment out of the IM store rather than changing priority alone.

Repopulation after eviction

After an eviction cycle, change priority with ALTER TABLE ... INMEMORY PRIORITY ..., then force repopulation with ALTER TABLE ... INMEMORY or DBMS_INMEMORY.POPULATE where supported. Verify population_status in V$IM_SEGMENTS before assuming the segment is resident again.

Missing diagnostic detail

Provide the current INMEMORY_SIZE and the summed INMEMORY_SIZE of the CRITICAL working set. If the critical set exceeds available memory, no priority staging or repopulation pattern will provide stable residency.

SELECT owner, segment_name, priority, population_status, bytes, inmemory_size
FROM V$IM_SEGMENTS
ORDER BY priority, population_status;

SELECT * FROM V$IM_MEMORY_CONSUMPTION;