OLTP压缩（Advanced Row Compression）

OLTP压缩（Advanced Row Compression）是Oracle 11gR1起推出的**实时、在线、行级**数据压缩技术，面向高并发事务处理场景，可在数据插入、更新、删除的同时自动完成压缩，无需批量加载或停机窗口。它打破了早期Basic Compression“只读优、DML劣”的局限，使“压缩”从数据仓库走向核心业务系统，成为现代Oracle数据库**节省存储、提升I/O、降低缓存压力**的默认选项。下文从原理、结构、触发、性能、空间、限制、诊断、案例、最佳实践九个维度，对OLTP压缩进行系统梳理。

一、定位与演进
1. 9iR2出现Basic Table Compression，仅对直接路径插入（Direct Path Load）生效，块内建“符号表”去重，DML后续行无法享受压缩，更新甚至膨胀。
2. 11gR1推出Advanced Compression选件，其中Advanced Row Compression（文档仍习惯叫OLTP压缩）支持**常规路径插入**（Conventional Insert）实时压缩，解决核心OLTP系统空间痛点。
3. 12c起，Advanced Row Compression成为“默认压缩子句”——CREATE TABLE不指定即使用ROW STORE COMPRESS ADVANCED；19c进一步引入**Hybrid Columnar Compression**双模式，但OLTP仍以行级实时压缩为主。
4. 授权：Advanced Compression属于Oracle Enterprise Edition的额外付费选件，需单独购买license；但在Oracle Cloud(DBCS/ExaCS/ATP)中已包含，无需额外付费。

二、压缩原理与块级结构
1. 符号表（Symbol Table）
每个数据块在第一次达到“压缩阈值”时，自动扫描块内所有行，提取重复值（整列或列片段）映射为短符号（1~3 Byte），符号表常驻块头，后续行存储符号而非原值。
2. 行格式不变
仍采用Oracle普通行头+列长+列值格式，只是列值被符号替代，因此无需解压即可通过行目录定位，**支持行级锁与MVCC**。
3. 触发阈值
块内已用空间达到**PCTFREE-1%**时触发压缩；若新插入导致块超阈值，Oracle先压缩再插入，若压缩后仍放不下，则进行行迁移或分裂。
4. 自适应算法
符号表并非静态：后续更新导致符号膨胀或新值进入，Oracle可在线重建符号表，甚至“解压缩”单块，保证DML自由度高。
5. 压缩比度量
典型字符型、状态位、重复日期等高冗余表可达**2×–4×**；随机数值、高更新率表约**1.3×–1.8×**；纯LOB或加密列无压缩收益。

三、DML路径与锁机制
1. INSERT
常规insert values/select均实时压缩；直接路径insert也兼容，优先使用符号表。
2. UPDATE
若更新列为符号列，新值在符号表存在则直接替换符号；不存在则扩展符号表或标记为非压缩存储。
3. DELETE
删除行仅做行目录标记，释放空间可用于后续插入，压缩状态保持；块内行数降至0时，符号表被清除。
4. 锁与并发
块级符号表变更需持有**TM**与**TX**锁，但粒度与普通表一致，**不会出现额外的队列等待**；高并发随机插入场景，符号表重建概率极低，性能衰减<3%。

四、空间与I/O收益
1. 存储节省
某省电信计费库，11g升级后打开OLTP压缩，**900 GB→360 GB**，节省60%；索引未压缩，但表收缩后索引同步缩小。
2. Buffer Cache效率
块体积减小，同等内存可容纳更多行，逻辑读命中率提升，CPU利用率下降；在TPC-C基准测试中，**tpmC提升8%–12%**。
3. redo/undo 量
符号化后列值变短，**redo生成量减少10%–30%**；undo因存储符号亦缩小，尤其更新状态位场景明显。
4. 全表扫描
扫描需解压，但解压在内存完成，CPU开销<5%，I/O减少带来的收益远高于CPU成本；Exadata下配合Storage Index可跳过大量块，进一步放大优势。

五、性能开销与权衡
1. CPU
压缩/解压缩算法纯内存操作，单核解压速度约**1–2 GB/s**，OLTP短事务CPU增加<5%；批量更新大字段场景需评估。
2. 延迟
插入触发压缩时，块内行数通常<200，延迟在**几十微秒级**，对毫秒级事务几乎无感。
3. 行迁移
压缩后块内预留更多空间，**反而降低行迁移概率**；实测高更新表迁移行比例由1.2%降至0.3%。
4. 加密与压缩顺序
先压缩后加密可提升压缩比；TDE列加密在压缩之后进行，互不影响；若使用**加密先于压缩**，则压缩比大幅下降。

六、使用与限制
1. 语法
表级：CREATE TABLE t (...) ROW STORE COMPRESS ADVANCED;
分区级：可对不同分区采用不同压缩策略，如历史分区Basic/Archive，热分区OLTP。
2. 最低兼容参数
COMPATIBLE≥11.1.0；段空间管理必须为ASSM（自动段空间管理），字典管理表空间不支持。
3. 不支持对象
集群表（Cluster）、索引组织表（IOT）的**非叶子块**、临时表、外部表、SYS用户表。
4. 列级限制
列定义>255字节的大字段（RAW/BLOB/CLOB）仅压缩内联部分，行外LOB段不压缩；使用**SECUREFILE LOB**可单独指定COMPRESS。
5. 降级
ALTER TABLE … NOCOMPRESS 需执行**ALTER TABLE MOVE**或在线重定义，直接修改数据字典不会解压缩现有块。

七、监控与诊断
1. 视图
DBA_TABLES.COMPRESSION=’ENABLED’, DBA_TAB_PARTITIONS.COMPRESS_FOR=’OLTP’
V$SEGMENT_SPACE_USAGE可查看压缩块比例。
2. 段顾问
DBMS_COMPRESSION.GET_COMPRESSION_RATIO可**在线采样**，估算压缩比，无需建影子表。
3. AWR
“Compress Block”与“Decompress Block”等待事件，CPU占用在DB CPU中体现，通常<5%。
4. 块dump
打开trace可看到符号表条目：
tab 0, row 0, @0x1f3c
tl: 11 fb: –H-FL– lb: 0x0 cc: 3
col 0: [ 2] c1 0b –> 符号0x0b映射到’ACTIVE’
col 1: [ 6] 54 49 43 4b 45 54

八、典型实施案例
1. 金融核心账户表
表规模2.5 TB，字段包含账户状态、币种、开户机构等高度重复列，启用OLTP压缩后降至900 GB，**每月归档I/O减少40%**，批处理窗口缩短1小时。
2. 运营商话单库
分区表按日分区，近期7天热分区用OLTP压缩，历史分区用Archive High；合计节省**68%存储**，X-IO全闪阵列延迟下降25%。
3. 零售ERP行表
高并发订单插入，CPU增加3%，但逻辑读减少30%，Buffer Cache可缓存更多热块，**双11峰值TPS提升10%**。

九、最佳实践与结论
1. 评估先行
使用DBMS_COMPRESSION.GET_COMPRESSION_RATIO对样本数据做**在线估算**，结合业务增长、CPU余量、I/O瓶颈综合决策。
2. 热数据优先
对状态位、类型码、日期、币种等**低基数列**高比例表，压缩收益最大；纯数值随机键值表收益有限。
3. 分区混合
采用**分层压缩策略**：热分区OLTP，温分区Basic，冷分区Archive；既保证实时压缩，又最大化历史数据压缩比。
4. 监控常态化
把“Compress Block CPU”纳入AWR基线，超过5%时评估是否需关闭部分分区压缩或扩容CPU。
5. 升级与授权
19c后OLTP压缩为默认，但**Advanced Compression选件需购买**；在Oracle Cloud已包含，可放心启用；混合云场景注意合规。
6. 结合新特性
与In-Memory、Memoptimize Rowstore、JSON列共用无冲突；In-Memory自动存储解压后列式，兼顾压缩与极速扫描。

结语
OLTP压缩让“存储节省”与“高并发”不再矛盾，使压缩技术从数据仓库的“奢侈品”变成核心交易库的“日用品”。只要遵循评估—试点—监控—优化的闭环，就能在CPU富余、I/O紧张的现代硬件架构下，**以个位数CPU增幅换取数倍空间节省与缓存命中率提升**，为业务高峰留出宝贵的磁盘带宽与内存资源，真正实现“降本、增效、提速”的三重目标。