oracle 19c中分区表启用高级行压缩（即compress for oltp）必须显式为每个分区指定，表级compress声明不自动继承；已存在分区需用move强制重写才能压缩历史数据。
oracle 19c 中对分区表启用 row store compress advanced（即高级行压缩）是可行的，但必须明确：它不能直接在表级 create table 语句中用 compress for oltp 一类语法“全局开启”后自动继承到所有分区——你得显式控制每个分区的压缩属性，否则未指定的分区默认不压缩。
分区级压缩必须显式声明，不能靠表级 inherit
即使你在 CREATE TABLE 里写了 COMPRESS FOR OLTP，Oracle 19c 也不会把它自动下推到每个分区定义中。实际生效的是「表级压缩属性」，但它只影响后续新增的、未显式指定压缩方式的分区；而已存在的分区或显式写出的分区定义，完全忽略该表级设置。
- 错误写法（以为能统一压缩）：
CREATE TABLE sales PARTITION BY RANGE(sale_date) COMPRESS FOR OLTP (...)→ 分区本身没写COMPRESS，结果全不压缩 - 正确写法（逐一分区指定）：
PARTITION p2023 VALUES LESS THAN (...) COMPRESS FOR OLTP,PARTITION p2024 VALUES LESS THAN (...) COMPRESS FOR OLTP - 若已有分区表，需用
ALTER TABLE ... MODIFY PARTITION ... COMPRESS FOR OLTP单独修改，且仅影响后续新插入/更新的数据，历史数据仍保持原状
COMPRESS FOR OLTP 和 COMPRESS FOR ADVANCED 是同一回事
在 Oracle 19c 文档和实际解析中，COMPRESS FOR OLTP 就是 ROW STORE COMPRESS ADVANCED 的简写别名，二者等价。SQL 引擎内部都映射为同一种压缩机制，行为一致：
- 支持任意 DML（单行 INSERT/UPDATE、批量 INSERT、MERGE）实时触发压缩
- 更新时只压缩被修改列所在行的新版本，未修改列保持原有压缩状态
- 块内达到阈值后自动重压缩（由数据库隐式触发，无需人工干预）
- 不支持
LOB列压缩（即使列在分区中），压缩仅作用于堆表行数据
ALTER TABLE MODIFY PARTITION 后数据不会自动重压缩
这是最容易被误解的一点：执行 ALTER TABLE sales MODIFY PARTITION p2023 COMPRESS FOR OLTP 只是“标记”该分区今后插入/更新走高级压缩路径，已存数据块仍维持原始存储格式（可能未压缩，或用 BASIC 压缩）。要真正压缩存量数据，必须触发重写：
- 方法一（推荐）：
ALTER TABLE sales MOVE PARTITION p2023 COMPRESS FOR OLTP—— 搬移过程强制重写并压缩全部行 - 方法二：用
INSERT /*+ APPEND */ INTO ... SELECT+EXCHANGE PARTITION替换，但需额外空间和维护窗口 - 注意：
MOVE会失效本地索引，需加UPDATE INDEXES或事后重建 - 执行前务必确认该分区无活跃 DML，否则
MOVE会持排他锁
查询压缩状态不能只看 USER_TABLES.COMPRESSION
USER_TABLES 的 COMPRESSION 字段只反映表级声明（如 ENABLED），无法体现各分区真实压缩方式。必须查 USER_TAB_PARTITIONS：
SELECT partition_name, compression, compress_for FROM user_tab_partitions WHERE table_name = 'SALES';
其中 compress_for 列才是关键：
– OLTP 表示高级行压缩已启用
– BASIC 表示仅 direct-path 加载压缩
– NONE 或空值表示未压缩
另外，compression 列显示 ENABLED 并不等于有效压缩，它只是说明该分区允许压缩，实际是否生效取决于 compress_for 和数据写入方式。
真正麻烦的不是语法怎么写，而是压缩策略必须和数据生命周期对齐：比如按月分区的历史表，新分区开 COMPRESS FOR OLTP，旧分区用 MOVE ... COMPRESS FOR ARCHIVE HIGH 进一步压，而归档冷数据分区甚至该设成 READ ONLY 配合 COMPRESS FOR QUERY HIGH。混用不匹配的压缩类型，反而会放大 CPU 开销，还查不出问题在哪。
