虚拟列分区与物化视图在19c可共存但仅支持complete刷新，因物化视图日志不支持虚拟列——其值不存储、不参与dml日志捕获，故无法追踪变化；需启用enable row movement以防刷新失败。
虚拟列分区 + 物化视图在 19c 中能共存，但必须绕开物化视图日志这个硬限制。直接在虚拟列分区表上建 ON COMMIT 或快速刷新物化视图会失败，因为物化视图日志不支持虚拟列（包括生成列）——这是 Oracle 官方明确禁止的，不是配置问题。
为什么物化视图日志不支持虚拟列？
物化视图日志依赖基表的行级变更记录，而虚拟列值不实际存储、不参与 DML 日志捕获。Oracle 无法在日志中可靠追踪虚拟列值变化，所以从 4.3.2 版本起（含 OceanBase 兼容行为）就彻底禁用该组合。
- 错误现象：
ORA-32313: REFRESH FAST of "MV_NAME" unsupported after modifications to master table或建日志时报ORA-32302: cannot create materialized view log on table with virtual columns - 适用场景：需要准实时聚合或 JOIN 预计算，且基表本身是按业务逻辑（如区域编码、金额区间）虚拟分区的
- 替代路径：只能用
COMPLETE刷新，或改用ON DEMAND+ 手动调度，无法依赖自动增量更新
如何让物化视图真正用上虚拟列分区裁剪？
关键不在“建”，而在“查”——只要物化视图定义里显式引用虚拟列，且基表已按该列分区，执行计划就能走分区裁剪。但注意：物化视图自身不继承基表分区结构，裁剪发生在查询重写阶段。
- 示例建法：
CREATE MATERIALIZED VIEW mv_sales_by_province REFRESH COMPLETE ON DEMAND AS SELECT province_code, SUM(amount) FROM sales_tab GROUP BY province_code;，其中province_code是基表上的虚拟列 - 查询时加
WHERE province_code = '01'，执行计划中能看到PARTITION RANGE SINGLE和Pstart=Pstop=1 - 性能影响：若物化视图未启用
ENABLE QUERY REWRITE，则即使基表分区再合理，也不会触发重写，纯当普通表扫描 - 兼容性注意：19c 支持
JSON_TABLE在物化视图中使用，但 JSON 字段若依赖虚拟列推导，仍受限于上述日志限制
ENABLE ROW MOVEMENT 必须开，否则刷新会失败
虚拟列值变化（比如更新原始列导致分区键重算）时，Oracle 需要移动行到新分区。物化视图刷新过程本质是 DELETE+INSERT，若基表没开 ENABLE ROW MOVEMENT，刷新会卡在 ORA-14402。
- 检查命令：
SELECT table_name, row_movement FROM user_tables WHERE table_name = 'SALES_TAB'; - 开启命令：
ALTER TABLE sales_tab ENABLE ROW MOVEMENT; - 容易踩的坑：只对主表开不够，如果物化视图还涉及其他分区表（如时间维表），那些表也得同步检查并开启
- 不开启的后果：第一次
REFRESH COMPLETE成功，但后续任意一次刷新都可能因某行需迁移而中断
真正麻烦的点不在语法，而在于刷新策略被迫降级后，数据新鲜度和资源消耗之间的权衡——你得自己决定是每小时全量刷一次，还是接受延迟几小时的数据。虚拟列分区帮你在查询端省下 90% 的 I/O，但代价是刷新成本全部摊到单次操作上。
