Oracle 12c ILM策略不自动移动数据，仅在Heat Map触发条件满足时调用ALTER TABLE MOVE PARTITION等DDL；需提前启用Heat Map、创建目标表空间并配置配额、手动处理索引与统计信息，且仅在维护窗口内执行。
Oracle 12c 的 ILM（Information Lifecycle Management）策略本身不自动移动数据，它只负责“触发条件满足时调用指定动作”；真正执行分层迁移的是 ALTER TABLE MOVE PARTITION 这类 DDL，而 Oracle 不会帮你建表空间、设只读、重建索引或开启 Heat Map——这些都得提前配齐，否则策略永远不生效。
必须先打开 Heat Map，否则 ILM 策略完全无效
Heat Map 是 ILM 的数据来源，关了它，ILM 就是瞎子。默认关闭，且只记录新写入/访问的数据行为，旧数据不会补记时间戳。
-
ALTER SYSTEM SET HEAT_MAP = ON;必须全局执行，不能按用户或表设置 - 开启后需等待至少 24 小时，
DBA_HEAT_MAP_SEGMENTS才开始有有效数据（如LAST_ACCESS_TIME） - 验证是否生效：
SELECT * FROM V$HEAT_MAP_SEGMENT WHERE SEGMENT_NAME = 'YOUR_TABLE';，查不到不是策略问题，是 Heat Map 还没攒够数据
MOVE PARTITION 动作必须显式指定目标表空间，且该表空间必须已存在
ILM 策略里写 TIER TO ts_cold，Oracle 就真去查这个表空间是否存在、当前用户是否有 QUOTA、是否启用了 ASSM（对压缩必需）。写错名、没创建、没配 quota，直接报 ORA-43853。
- 目标表空间必须提前创建：
CREATE TABLESPACE ts_cold DATAFILE '/u01/oradata/.../ts_cold01.dbf' SIZE 1G SEGMENT SPACE MANAGEMENT AUTO; - 确保用户有配额：
ALTER USER app_user QUOTA UNLIMITED ON ts_cold; - 策略中必须写真实存在的表空间名，不能用别名、不能拼错、不能依赖“自动创建”
MOVE PARTITION 后的索引、统计信息和只读状态全要手动处理
Oracle 不会因为策略里写了 MOVE PARTITION 就顺手把索引也搬过去、把统计信息更新了、把分区锁住。这些全是独立操作，漏一项就可能引发查询失败或性能骤降。
- 本地索引可用
UPDATE INDEXES子句一并重建，但全局索引仍会变UNUSABLE，必须手动ALTER INDEX ... REBUILD - 分区级统计信息在
MOVE PARTITION后清空，必须立刻执行：DBMS_STATS.GATHER_TABLE_STATS(..., GRANULARITY => 'PARTITION') - 冷分区迁移后应立即设为只读：
ALTER TABLE t MODIFY PARTITION p_2022 READ ONLY;，否则后续写入会破坏分层逻辑
策略执行时机受维护窗口控制，不是定义完就跑
ILM 由后台进程 ILM_RUN 触发，且只在数据库维护窗口（Maintenance Window）内运行，默认是每天凌晨 2:00–6:00。不在窗口期，策略匹配了也不会执行。
- 检查窗口状态：
SELECT WINDOW_NAME, ENABLED FROM DBA_SCHEDULER_WINDOWS; - 手动触发一次（仅用于验证）：
EXEC DBMS_ILM.EXECUTE_ILM(ilm_scope => DBMS_ILM.ILM_SCOPE_SCHEMA); - 策略判断依据是
DBA_HEAT_MAP_SEGMENTS.LAST_ACCESS_TIME，不是分区键值——哪怕你按ORDER_DATE分区，ILM 仍看“最后一次被 SELECT/UPDATE 的时间”来判定冷热
最容易被忽略的是：迁移完成后，DBA_SEGMENTS.BYTES 和空间使用统计有几分钟延迟，刚执行完 MOVE PARTITION 就查空间是否释放，大概率看到的是旧值；别急着报警，等 5 分钟再确认。
