必须先设非零INMEMORY_SIZE并重启，否则所有配置无效；需用SCOPE=SPFILE设置（如4G），重启后查V$INMEMORY_AREA确认ALLOCATED_BYTES>0才算真正启用。
必须先设非零 INMEMORY_SIZE 并重启，否则所有配置都无效
Oracle 19c 的 In-Memory 功能不是靠 ALTER TABLE 启动的，它依赖一块独立的 SGA 子区域。如果 INMEMORY_SIZE 是 0（默认值），哪怕你对表加了 INMEMORY 属性，Oracle 也会静默忽略——不会报错，也不会加载，执行计划里永远看不到 TABLE ACCESS INMEMORY FULL。
- 检查当前值：
SHOW PARAMETER inmemory_size；若返回 0，说明未启用 - 最小有效值是
100M，低于这个值 Oracle 会直接跳过初始化 - 必须用
SCOPE=SPFILE设置，例如：ALTER SYSTEM SET inmemory_size=4G SCOPE=SPFILE - 该参数不支持热加载，
SCOPE=BOTH会报ORA-02095，改完必须重启实例 - 多租户环境下，
INMEMORY_SIZE必须在 CDB 级设置，PDB 中设无效
怎么确认 In-Memory Area 真正分配成功？
光看参数值不够，得查底层视图。Oracle 启动时若发现 INMEMORY_SIZE > 0，才会尝试分配内存池；分配失败也不会报错，只是 V$INMEMORY_AREA 返回空行。
- 执行
SELECT * FROM V$INMEMORY_AREA：有记录且ALLOCATED_BYTES > 0才算真正就位 - 若返回空，说明参数虽设但未生效——常见于没重启、或
/dev/shm不足（尤其和MEMORY_TARGET共存时） -
V$INMEMORY_SEGMENTS刚启用时空是正常的，它只记录已触发加载的对象，不是声明列表 - 注意
V$INMEMORY_AREA.POPULATE_STATUS字段：值为COMPLETED表示加载完成，NOT POPULATED不代表失败，只是还没开始
大表启用 INMEMORY 时，粒度和压缩策略怎么选？
对大宽表直接 ALTER TABLE t INMEMORY 容易引发内存水位暴涨、POPULATE 卡住甚至 OOM。关键不是“能不能进”，而是“哪些数据值得进”和“怎么省着进”。
- 优先列级指定：
ALTER TABLE sales INMEMORY (time_id, prod_id, amount_sold)，排除 LOB、XMLTYPE、超长 VARCHAR2（>4000 字节） - 分区表务必分区级加载：
ALTER TABLE sales MODIFY PARTITION p_2025_q1 INMEMORY，避免冷分区挤占热数据空间 - 压缩级别影响实际内存占用：
MEMCOMPRESS FOR CAPACITY HIGH比默认FOR QUERY LOW节省约 40% 内存，适合高重复度字段（如状态码、地区编码） - 禁用
INMEMORY PRIORITY CRITICAL：它会强制抢占全部可用 IM 内存，导致其他表加载阻塞 - IOT 和全局临时表（GTT）不支持
INMEMORY，会报ORA-64307
备库启用 In-Memory 有哪些特殊限制？
ADG 备库不会自动继承主库的 In-Memory 配置。即使主库开了，备库的 INMEMORY_SIZE 默认仍是 0，且 inmemory_adg_enabled=TRUE 只表示“允许启用”，不是“已启用”。
- 查备库：
SHOW PARAMETER inmemory_size，结果为 0 就必须手动配 - 不能直接改备库 SPFILE——ADG 下 SPFILE 通常由主库管理，硬改可能被覆盖
- 推荐方案：在备库的 PDB 中执行
ALTER SYSTEM SET inmemory_size=4G SCOPE=SPFILE，再重启该 PDB - RAC 环境下还需确认：
parallel_degree_policy = AUTO且parallel_force_local = FALSE，否则 IM 列存储不参与并行查询 - 首次查询才触发加载，首条 SQL 会慢（磁盘读 + 解压 + 列转存），这是设计行为，不是异常
最常被跳过的动作是确认 V$INMEMORY_AREA 是否真有分配记录——很多人看到参数设了、表加了属性、执行计划也“看起来正常”，就以为启用了，结果性能毫无变化。内存没真正分出去，后面所有操作都是空中楼阁。
