COMPRESS FOR OLTP需显式指定且依赖Advanced Compression许可，而COMPRESS仅为BASIC压缩简写，仅对直接路径插入生效；二者核心区别在于OLTP压缩支持实时DML压缩并由SMON后台清理，BASIC则不支持常规UPDATE/DELETE压缩。
必须显式启用 COMPRESS FOR OLTP，仅写 COMPRESS 无效，且需确认许可可用。
COMPRESS FOR OLTP 和 COMPRESS 的本质区别
Oracle 19c 中 COMPRESS 是 BASIC 压缩的简写，只在直路插入（INSERT /*+ APPEND */）时生效；而 COMPRESS FOR OLTP 才是真正支持 UPDATE/DELETE 实时压缩的高级行压缩机制。
-
CREATE TABLE t1 COMPRESS ...→ 实际等价于COMPRESS BASIC，后续常规 DML 不压缩 -
CREATE TABLE t1 COMPRESS FOR OLTP→ 启用 OLTP 压缩逻辑，SMON 后台自动清理未压缩行 -
ALTER TABLE t1 COMPRESS FOR OLTP→ 对已有表启用，但不会立即重写旧数据块，需配合MOVE或等待后台清理
执行前必须验证的三项许可与配置
即使语法正确，COMPRESS FOR OLTP 在 19c 中仍可能静默失效——它依赖 Advanced Compression Option 许可，且企业版才支持。
- 检查是否已授权：运行
SELECT * FROM v$option WHERE parameter = 'Advanced Compression';，返回TRUE才可用 - 确认数据库版本与 edition：
SELECT banner_full FROM v$version;必须含Enterprise Edition - 标准版（Standard Edition）下执行
COMPRESS FOR OLTP不报错，但实际存储无压缩效果，DBA_TABLES.COMPRESSION可能显示ENABLED，但DBA_SEGMENTS.BYTES不降
如何验证压缩是否真实生效
别信 DBA_TABLES.COMPRESSION = 'ENABLED'，那只是定义状态。真压缩看空间和块内容。
- 执行
ANALYZE TABLE t1 COMPUTE STATISTICS;后查DBA_TABLES.AVG_ROW_LEN：若明显小于建表前预估（如从 200B 降到 85B），说明压缩起效 - 对比
DBA_SEGMENTS.BYTES与DBA_TABLES.BLOCKS * 8192：前者显著小于后者，说明有空闲空间被回收（压缩 + HWM 下降） - 观察
V$SESSION_LONGOPS：启用后若存在OLTP Compression Cleanup类型任务，说明 SMON 正在后台整理
常见误操作与锁行为陷阱
直接对大表执行 ALTER TABLE ... COMPRESS FOR OLTP 不会锁表，但后续首次 UPDATE 可能触发隐式 MOVE 类操作，引发意外阻塞。
- 对在线业务表，优先用
ALTER TABLE t1 MOVE COMPRESS FOR OLTP：一次性重组织并压缩，但需排他锁（X 锁），建议在维护窗口执行 - 分区表不能整表
MOVE，必须逐个分区处理：ALTER TABLE t1 MODIFY PARTITION p2024 SHRINK SPACE COMPACT+ALTER TABLE t1 MODIFY PARTITION p2024 COMPRESS FOR OLTP - 含
SECUREFILE LOB列的表，LOB 段不随主表压缩，必须单独执行：ALTER TABLE t1 MODIFY LOB (col_lob) (SHRINK SPACE)
最易被忽略的是：启用 COMPRESS FOR OLTP 后，必须手动执行 DBMS_STATS.GATHER_TABLE_STATS。否则优化器仍按旧 AVG_ROW_LEN 和 BLOCKS 估算执行计划，可能导致全表扫描变慢、索引选择率失真。这不是压缩本身的问题，而是统计信息滞后带来的连锁反应。
