备库启用Database In-Memory需手动单独开启并填充：先确认v$option中“In-Memory Column Store”为TRUE，再设INMEMORY_SIZE（静态参数，须重启）、执行ALTER TABLE … INMEMORY，并在ADG READ ONLY WITH APPLY模式下手动触发查询以完成填充。
备库上启用 Database In-Memory 无需主库同步，但必须手动在备库单独开启并填充；否则即使配置了参数，INMEMORY 列也不会被加载到内存列存储中。
备库必须显式启用 INMEMORY 并手动触发填充
Oracle Data Guard 的物理备库默认不继承主库的 INMEMORY 配置，哪怕主库已启用且表加了 INMEMORY 属性，备库上的对应对象仍处于“未加载”状态。这是因为内存列存储是实例级资源，不会通过 Redo 传输。
- 检查备库是否已启用：运行
SELECT parameter, value FROM v$option WHERE parameter = 'In-Memory Column Store';—— 输出必须为TRUE - 确认参数已设：备库需显式执行
ALTER SYSTEM SET INMEMORY_SIZE = 4G SCOPE=SPFILE;（值需根据物理内存合理分配，建议 ≤40%） - 重启备库使参数生效（
INMEMORY_SIZE是静态参数，无法动态修改） - 启动后手动填充：执行
ALTER TABLE sales INMEMORY;或对整个 PDB 执行ALTER PLUGGABLE DATABASE sales_pdb ENABLE INMEMORY;
备库 INMEMORY 填充失败的常见原因
填充卡住或 V$INMEMORY_AREA 显示 USED_BYTES = 0，往往不是配置错，而是同步机制没绕过去。
- 备库必须处于
OPEN READ ONLY WITH APPLY模式（即 ADG 模式），不能是 MOUNT 状态 —— 否则INMEMORY加载线程不启动 - 填充操作本身不走 Redo，所以主库上做的
ALTER TABLE ... INMEMORY不会传到备库，必须在备库本地执行 - 如果表有大量 LOB 或未压缩的高基数列，首次填充可能超时；可先用
NO INMEMORY清理再重试 - 检查
V$INMEMORY_POPULATE：若STATE长期为POPULATING，大概率是内存不足或并发填充太多，需调小INMEMORY_PRIORITY
与 ADG DML 重定向共存时的注意事项
当备库同时启用了 ADG_REDIRECT_DML 和 INMEMORY，DML 重定向本身不影响内存列加载，但要注意查询路径一致性。
- DML 重定向只影响写操作，所有 SELECT 仍完全在备库本地执行，因此
INMEMORY加速只作用于备库发起的查询 - 如果应用连接的是备库但执行了重定向 DML，随后立即查同一张表，可能因 Redo 应用延迟导致内存中数据未及时刷新 —— 这不是 bug，是最终一致性模型的自然表现
- 避免在备库对
INMEMORY表频繁执行重定向 DML：每次重定向都会触发主库生成 Redo，再传回备库应用，间接增加内存列区域的脏块清理压力
最易被忽略的一点：备库的 INMEMORY 内存池和主库完全独立，连大小都可以不同；但如果你依赖物化视图或 JSON_TABLE 查询重写，得确保备库的 COMPATIBLE 参数不低于主库，否则某些优化器特性会静默失效。
