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

A mixed analytic workload needs reliable response times for both hot tables marked INMEMORY_PRIORITY CRITICAL and ad-hoc tables set to NONE. The goal is to size the IM column store so that critical segments remain resident while on-demand segments can be evicted without destabilizing query latency. However, Oracle documents that INMEMORY_PRIORITY governs population order rather than residency guarantees, and the internal eviction algorithm that weighs access frequency and priority is not fully specified.

Because exact eviction thresholds are undocumented and may differ across Oracle Database releases, tuning by priority alone leaves uncertainty. Changing an object's priority after it is already populated does not force an immediate reload; the new setting only applies after eviction or a manual repopulation. Monitoring views report population status but do not expose the internal scores used for eviction decisions, making it difficult to verify whether a NONE-priority segment will survive a memory-pressure event.

Given these limits, what design patterns are appropriate for workloads that combine fixed-priority and on-demand IM segments under a fixed INMEMORY_SIZE? Are there documented release-specific differences in eviction behavior between Oracle 19c and later versions that affect this design? How should INMEMORY_PRIORITY be staged when segments must be repopulated after an eviction cycle?