Oracle 19c大型物化视图压缩配置节省空间

先说一个最容易被忽略的前提：物化视图必须在 CREATE 时显式加上 COMPRESS，否则哪怕把物化视图建在压缩表空间里，数据块也依然是未压缩的。这个坑，踩过的人往往要重新跑一轮数据才能意识到。

为什么 ALTER MATERIALIZED VIEW 不能加 COMPRESS？

Oracle 的规则有点死板——ALTER MATERIALIZED VIEW ... COMPRESS 这条路行不通。物化视图底层本质上是一张普通表，但DDL层并不开放压缩属性的切换。一旦试图执行，就会碰到 ORA-00922: missing or invalid option。

• 唯一的可行路径：要么 DROP 后重建，要么退而求其次：对底层表直接执行 ALTER TABLE mv_name COMPRESS FOR OLTP。需要注意权限和锁的问题。
• 重建前，务必确认刷新策略是否支持中断。尤其是 ON COMMIT 类型的物化视图，重建期间基表的DML会阻塞。
• 如果物化视图名为 mv_sales_daily，其实际存储的表名通常也是 MV_SALES_DAILY，可以通过 SELECT mview_name, table_name FROM user_mviews 验证。

COMPRESS FOR OLTP 和 COMPRESS BASIC 怎么选？

压缩类型选错了，空间节省可能大打折扣，甚至可能影响刷新性能。这里有两个关键点：

• COMPRESS BASIC：只对直接路径操作（如 INSERT /*+ APPEND */）生效。普通的 INSERT 或 UPDATE 会解压整个数据块，后续的 FAST 刷新可能会让空间反复膨胀。
• COMPRESS FOR OLTP：支持常规DML压缩，适合频繁刷新的场景。但前提是需要企业版 + Advanced Compression 选件，否则会报 ORA-64307。
• 如何验证是否启用？执行 SELECT table_name, compression, compress_for FROM user_tables WHERE table_name = 'MV_SALES_DAILY' —— 注意关注 compress_for 字段的值。

分区物化视图怎么压缩才真正省空间？

如果只是给整个物化视图加上 COMPRESS，效果往往有限。真正能释放冷数据的，是分区级别的压缩。

• 分区键必须与基表对齐（aligned），否则无法使用 FAST 刷新。举个例子：如果基表按 sale_date 范围分区，物化视图也得用 TRUNC(sale_date, 'MM') 分区。
• 建物化视图时，可以为每个分区单独声明压缩：PARTITION p_202501 COMPRESS FOR OLTP。对于已有分区，可以使用 ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p_202501 COMPRESS FOR OLTP。
• 老分区直接 DROP PARTITION 清理，比 DELETE 或 TRUNCATE 更快，而且不会产生大量的 undo/redo。

空间没降下来？先查这三个地方

加了 COMPRESS 但空间依然居高不下，大概率不是压缩没生效，而是其他环节在“偷吃空间”。

• 基表本身未压缩：物化视图只压缩自己的数据，不会压缩源表。如果基表的数据冗余较高，物化视图刷新时读取的原始块就多，压缩率天然受限。
• 物化视图日志（MLOG$）堆积：FAST 刷新依赖日志表，如果长期不做 DBMS_MVIEW.PURGE_LOG，日志表会膨胀。这部分数据不受物化视图的 COMPRESS 影响。
• 刷新方式为 COMPLETE：全量重建期间，旧段不会立即释放，会临时占用双倍空间。建议改用 FAST 或 FORCE，并确保基表有日志。

压缩这东西，真不是一劳永逸的开关。它依赖基表结构、刷新机制、分区设计三者的协同。单独去调物化视图的 COMPRESS 参数，就像只换轮胎却不做四轮定位——能跑，但跑不远。