Oracle 19c中怎样为大型物化视图配置压缩以节省空间？

物化视图必须在CREATE时显式指定COMPRESS，ALTER MATERIALIZED VIEW不支持修改压缩属性，唯一方法是DROP重建或对底层表执行ALTER TABLE COMPRESS；压缩类型需按刷新频率和版本选COMPRESS FOR OLTP（企业版）或COMPRESS BASIC，并配合分区级压缩、基表压缩及日志清理才能真正节省空间。

物化视图必须在 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 类型的 MV 重建期间基表 DML 会阻塞
• 若 MV 名为 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 字段值

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

单纯给整个 MV 加 COMPRESS 效果有限；分区级压缩才能切片释放冷数据。

• 分区键必须与基表对齐（aligned），否则无法使用 FAST 刷新；例如基表按 sale_date 范围分区，MV 也得用 TRUNC(sale_date, 'MM') 分区
• 建 MV 时每个分区单独声明压缩：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 还占满空间，大概率不是压缩没生效，而是其他环节在“偷偷吃空间”。

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

压缩不是一劳永逸的开关，它依赖基表结构、刷新机制、分区设计三者协同；单独改 MV 的 COMPRESS 参数，就像只换轮胎不调四轮定位——能跑，但跑不远。