Heat Map和ADO不自动分区，仅标记冷热数据并触发动作；真正迁移数据需手动执行ALTER TABLE MOVE PARTITION等DDL，且表空间、只读设置、索引重建等均须预先配置。
Heat Map 和 ADO 本身不自动“分区”，它们只负责标记冷热数据并触发动作；真正移动数据的是你写的 ALTER TABLE MOVE PARTITION 这类 DDL，而 Oracle 绝不会帮你建表空间、设只读、重建索引——这些都得提前配好。
Heat Map 记录的是访问时间，不是分区键值
Heat Map 按段（segment）粒度记录 LAST_ACCESS_TIME 和 LAST_WRITE_TIME，存于 V$HEAT_MAP_SEGMENT。它不管你的分区键是 sale_date 还是 region，只看整个分区（或整个非分区表）最近有没有被 SELECT/UPDATE/INSERT 触及。
- 常见误判现象：某分区里只有 1 行被查过，
LAST_ACCESS_TIME就会刷新，整分区被标记为“热”，哪怕其余 99.9% 数据半年没碰过 - 查询验证：
SELECT SEGMENT_NAME, PARTITION_NAME, LAST_ACCESS_TIME, LAST_WRITE_TIME FROM V$HEAT_MAP_SEGMENT WHERE SEGMENT_NAME = 'SALES';
- 注意：该视图数据有延迟，刚访问完可能查不到更新，需等后台进程刷新（默认每 24 小时一次，且依赖
DBMS_HEAT_MAP.START_HEAT_MAP全局开启）
ADO 策略只定义“什么条件下触发什么动作”，不执行动作
ADO（Automatic Data Optimization）策略本质是一组元数据规则，挂载在表或分区上，由后台作业 ILM_RUN 在维护窗口内扫描匹配，再调用对应 DDL。
- 错误认知：“建了策略就自动挪数据” → 实际上策略只是个“待办清单”，执行靠
DBMS_ILM.EXECUTE_ILM或定时窗口 - 必须显式指定目标：
TIER TO ts_cold中的ts_cold必须是已存在、用户有QUOTA、且启用了SEGMENT SPACE MANAGEMENT AUTO的表空间 - 不支持模糊匹配：写
TIER TO cold_storage（别名或未创建表空间）直接报ORA-43853
MOVE PARTITION 是唯一能真正迁移数据的操作，但它会锁表
ALTER TABLE ... MOVE PARTITION 是 ILM 策略背后实际干活的命令，但它的副作用必须手动兜底：
-
UPDATE INDEXES只重建本地索引结构，不更新统计信息 → 迁移后立刻执行DBMS_STATS.GATHER_TABLE_STATS(..., GRANULARITY => 'PARTITION') - 全局索引不会自动维护 → 必须加
UPDATE GLOBAL INDEXES或事后ALTER INDEX ... REBUILD - LOB 字段默认不动 → 必须显式写出
LOB (col_name) STORE AS (TABLESPACE ts_cold) - 分区不会自动变只读 → 需额外执行
ALTER TABLE ... MODIFY PARTITION ... READ ONLY
维护窗口和手动触发才是控制节奏的关键
ILM_RUN 默认只在数据库维护窗口（如每天凌晨 2:00–6:00）运行，且受 DBA_SCHEDULER_WINDOWS 控制：
- 查当前窗口是否启用：
SELECT WINDOW_NAME, ENABLED FROM DBA_SCHEDULER_WINDOWS;
- 手动跑一次（调试用）：
EXEC DBMS_ILM.EXECUTE_ILM(ilm_scope => DBMS_ILM.ILM_SCOPE_SCHEMA); - 策略生效 ≠ 数据立刻迁移：元数据更新即时，但
DBA_SEGMENTS.BYTES等空间统计可能延迟几分钟，别靠它判断是否完成
最常被忽略的一点：所有这些机制都建立在“你已预先建好冷热表空间、配好压缩属性、留好索引重建钩子”的前提上。Oracle 不会猜你要什么，它只按你写的规则机械执行。
