在Oracle 12c之前，数据库管理员若想实现数据分层存储，往往需要依赖应用侧逻辑或定期编写脚本分析表的访问模式。这种人工方式不仅滞后，而且容易漏掉那些访问频率突然下降但体积庞大的历史表。Oracle 12c引入的Heat Map机制从根本上改变了这一现状。它在数据库内部自动追踪行级和段级的数据访问情况，包括查询、插入、更新以及全表扫描等操作，采集过程不依赖外部工具，开销极低。Heat Map收集到的统计信息可以直接驱动Automatic Data Optimization（ADO）策略，由策略自动触发压缩、移动表空间等操作，实现冷热数据的透明分层，在性能与存储成本之间找到合理平衡。
Heat Map的统计维度与底层采集机制
Heat Map的核心价值在于它把数据访问行为量化为可查询的统计信息。在段级别，Oracle记录每个表、分区、索引或物化视图的读写时间，包括最近一次的segment_write_time（段写入时间）、segment_read_time（段读取时间）、full_scan（全表扫描次数）以及lookup_scan（索引查找扫描次数）。这些数据存储在数据字典中，可以通过DBA_HEAT_MAP_SEGMENT视图查询。行级别则更进一步，Oracle记录每一行在何时被插入、更新或查询，行级统计信息保存在DBA_HEAT_MAP_SEG_HISTOGRAM视图中，以时间区间聚合展示。通过行级数据，DBA能够精准判断某一分区内哪些行长期未被访问，从而为行级ADO策略提供依据。
Heat Map的采集过程由数据库后台进程异步完成，不会在访问路径上增加锁竞争或产生额外的重做日志。当用户执行SELECT、INSERT或UPDATE时，Oracle会在内存中记录访问标志，之后由后台将脏标志批量刷入数据字典。这种设计使得Heat Map在绝大多数OLTP和OLAP环境下开销极低，几乎可以忽略不计。不过需要注意的是，Heat Map默认是启用的，但如果确认业务完全不需要自动数据优化，可以通过参数heat_map将其关闭，以进一步节省资源。下方查询可以展示一个销售表在段级别的访问热度统计：
SELECT owner, object_name, subobject_name, object_type,
segment_write_time, segment_read_time,
full_scan, lookup_scan
FROM dba_heat_map_segment
WHERE object_name = 'SALES';
理解这些统计维度之后，就可以设计具体的ADO策略。Heat Map本身并不会做出任何优化动作，它只是提供事实数据，真正的自动化动作需要通过ADO策略来定义和触发。
定义ADO策略实现自动压缩与自主分层
Automatic Data Optimization策略分为两大类：压缩策略和存储分层策略。压缩策略可以基于Heat Map统计自动对段或行执行压缩，例如当某个分区的数据超过30天没有发生修改时，将其压缩为Advanced Compression格式。存储分层策略则可以把长时间未被访问的段或行移动到成本更低的表空间，比如从SSD所在的表空间迁移到SATA盘或云存储层。最常用的语法是利用ALTER TABLE ... ILM ADD POLICY来添加策略，并且可以同时定义多个策略，实现先压缩再迁移的组合动作。
下面的示例为SALES表创建一个压缩策略：如果某个分区超过30天没有数据修改（NO MODIFICATION），就自动执行高级压缩。Heat Map中的segment_write_time和行级写入时间戳会用来判断是否满足条件。
ALTER TABLE sales ILM ADD POLICY ROW STORE COMPRESS ADVANCED SEGMENT AFTER 30 DAYS OF NO MODIFICATION;
另一个示例是将超过90天没有任何访问（NO ACCESS）的分区自动移动到名为low_cost_ts的低成本表空间。这里NO ACCESS同时考虑了读取和写入，Heat Map的段读取时间和行级查询记录都会参与评估。
ALTER TABLE sales ILM ADD POLICY TIER TO low_cost_ts SEGMENT AFTER 90 DAYS OF NO ACCESS;
ADO策略创建之后，Oracle会通过维护窗口定期评估这些策略，默认每天执行一次。评估过程由MMON后台进程发起，如果发现有符合条件的对象，就会自动生成任务并由DBMS_SCHEDULER执行。管理员也可以手动调用DBMS_ILM.EXECUTE_ILM来强制执行所有未处理的策略，这在测试或者需要立即实现存储回收的场景中非常有用。通过DBA_ILMPOLICIES和DBA_ILMEVALUATIONDETAILS视图可以查看策略定义和每次评估的详细结果。
SELECT policy_name, object_name, subobject_name, object_type,
inherited_from, enabled, deleted
FROM dba_ilmobjects
WHERE object_name = 'SALES';
需要注意的是，行级策略在执行移动操作前必须启用行移动功能，否则Oracle会抛出错误。对于段级迁移，Oracle会使用在线数据移动技术，尽可能减少对业务的影响，但迁移期间仍会产生一定的I/O压力，因此建议将自动评估窗口安排在业务低峰期。
实际应用中的注意事项与策略组合建议
Heat Map与ADO虽然自动化程度很高，但并不意味着可以完全放手不管。一个常见的误区是认为Heat Map会自动识别冷热数据并直接触发优化，实际上Heat Map只负责采集统计信息，真正判定冷热的标准必须由DBA通过策略中的天数阈值来定义。例如，一个每天都有少量查询的归档表，如果使用NO ACCESS策略，可能永远不会被移动，但它同样占据着昂贵的主存储空间。因此制定策略前应当分析业务的访问规律，而不是直接套用固定天数。
策略组合顺序也会影响最终效果。对于纯历史数据，建议先执行压缩策略减少数据体积，再执行存储分层移动，这样可以在迁移时减少网络和磁盘传输量。而对于那些偶尔需要读取但很少修改的数据，先移动再压缩可能更合适，因为移动之后往往使用较低性能的CPU，压缩操作不会影响在线业务。此外，压缩策略会增加CPU开销，特别是在高并发写入场景下需要谨慎评估。存储移动策略则会造成I/O波动，建议利用Oracle的在线移动特性，并通过设置PARALLEL参数来加速迁移过程。
ALTER TABLE sales ENABLE ROW MOVEMENT;
另一个容易被忽略的点是许可问题。使用Heat Map本身不需要额外授权，但ADO策略中涉及的Advanced Compression、Tablespace Encryption或Automatic Data Optimization功能需要对应版本的Oracle Advanced Compression Option许可。部署前应确认许可合规。总体来说，Oracle 12c的Heat Map与ADO组合提供了一套数据库原生的数据生命周期管理方案，尤其适合数据量增长快、冷热数据界限清晰的应用场景，可以显著减少人工运维成本，并提高整体存储资源利用率。
Oracle Heat Map自动数据优化数据生命周期管理修改时间：2026-09-18 04:47:27