Oracle 12c+表空间不支持设置默认压缩类型，压缩策略必须在创建或修改表时显式指定（如COMPRESS FOR QUERY LOW），且需启用Advanced Compression许可并在Exadata等支持硬件上才能使用HCC高级压缩。
Oracle 12c+ 中 ALTER TABLESPACE 无法直接设默认压缩类型
表空间本身不支持“默认压缩策略”这种配置——default compress for oltp 或 default compress for query low 这类语法在 create tablespace 或 alter tablespace 里根本无效，oracle 会报 ora-02236 或直接忽略。真正起作用的是表/分区/物化视图创建时显式指定的压缩子句，以及表空间的 deferred_segment_creation 和底层存储属性（如 asm diskgroup 的 compatible.asm）。
实操建议：
- 新建表时必须写明压缩类型，例如：
CREATE TABLE t1 (...) COMPRESS FOR QUERY LOW - 想批量统一压缩策略？用
DBMS_REDEFINITION或ALTER TABLE ... MOVE COMPRESS FOR ...逐个改，没有“一键继承表空间默认值”的路径 - 检查当前表是否启用 HCC：查
USER_TABLES.COMPRESSION和USER_TABLES.COMPRESS_FOR，注意'ENABLED'不代表 HCC，得是'QUERY LOW'/'ARCHIVE HIGH'等具体值
Advanced Compression 选项没开，COMPRESS FOR 语法仍能执行但实际不生效
很多 DBA 以为只要语法通过就压缩成功了，结果发现段大小没变、查询也没加速。根本原因是 Advanced Compression 是独立许可选项，未启用时 Oracle 会静默降级：把 COMPRESS FOR QUERY LOW 当成基础 BASIC 压缩处理（即仅行内重复前缀压缩），完全跳过 HCC 的列级字典和深度编码逻辑。
实操建议：
- 确认许可状态：查
V$OPTION视图，PARAMETER = 'Advanced Compression'对应的VALUE必须为TRUE - 验证是否真走 HCC：运行
SELECT * FROM V$SEGMENT_STATISTICS WHERE STATISTIC_NAME = 'physical reads direct' AND OBJECT_NAME = 'YOUR_TABLE';，HCC 表在全表扫描时该值显著偏高（因直接读压缩块） - 别信
DBA_SEGMENTS.BLOCKS的数字——HCC 块内实际存多倍数据，BLOCKS反映的是分配的压缩后块数，不是原始逻辑块数
ALTER TABLE ... MOVE COMPRESS FOR 会重建段，但可能触发隐式锁和空间翻倍
在线重定义看似平滑，但 MOVE 操作本质是建新段、搬数据、删旧段。对大表而言，这不仅是时间问题，更是空间和锁的问题：原表在 MOVE 过程中会被加 EXCLUSIVE 锁（非只读），且临时需要等量空闲空间存放新压缩段。
实操建议：
- MOVE 前务必检查表空间剩余空间：至少预留等于当前
DBA_SEGMENTS.BYTES的空闲量 - 避免高峰期执行；若业务不能停写，优先选
DBMS_REDEFINITION（支持在线重定义，但需额外空间和更长窗口） -
MOVE COMPRESS FOR ARCHIVE HIGH对已有数据效果常不如预期——HCC 高压比依赖数据分布规律，乱序插入的老表压缩率可能仅 1.2x，远低于文档写的 10x
混合列压缩（HCC）只在 Exadata 和 Pillar Axiom 上完整支持
普通 Oracle 数据库（Linux x86、VMware、OCI 自建 DB）即使开了 Advanced Compression 许可，也只支持 QUERY LOW 和 QUERY HIGH，ARCHIVE LOW 和 ARCHIVE HIGH 会报 ORA-64307：“hybrid columnar compression is only supported in Exadata storage”。这不是 bug，是硬性限制。
实操建议：
- 别在非 Exadata 环境尝试
COMPRESS FOR ARCHIVE HIGH，语法解析阶段就会失败 - Exadata 用户注意：HCC 效果高度依赖数据加载方式——直接路径插入（
INSERT /*+ APPEND */）才能触发，常规 DML 插入进的是 BASIC 压缩块 - 迁移前务必测试：同一张表，在 Exadata 上用
QUERY HIGH压缩后导出再导入到非 Exadata 库，导入时自动退化为BASIC，且不可逆
最易被忽略的一点：HCC 压缩块的 undo 和 redo 行为与普通块不同，开启 HCC 后，UNDO_RETENTION 和 LOG_BUFFER 的调优逻辑要重新评估，尤其在大量小事务更新 HCC 表时，undo 段膨胀速度可能超预期。
