ILM策略不能自动迁移数据，需配合ALTER TABLE MOVE PARTITION等DDL及预置表空间、Heat Map启用（全局开启且24小时后生效）、手动维护索引与只读状态；其执行依赖维护窗口，元数据即时更新但空间统计有延迟。
ilm 策略本身不能直接“自动把数据挪到不同表空间”，它只负责触发动作；真正执行迁移的是 alter table move partition 这类 ddl，而 oracle 不会自动帮你建表空间、设只读、同步索引——这些都得你提前配好、留好钩子。
ILM 策略依赖 Heat Map 数据，必须先打开
Heat Map 是 ILM 的眼睛，关了它，ILM 就是瞎子。默认关闭，且只影响新写入数据（旧数据访问/修改不会补记）：
-
ALTER SYSTEM SET HEAT_MAP = ON;—— 必须全局开启，不能只对某个用户或表 - 开启后需等至少 24 小时，
DBA_HEAT_MAP_SEGMENTS才开始有有效数据（访问/修改时间戳） - 确认是否生效：
SELECT * FROM V$HEAT_MAP_SEGMENT WHERE SEGMENT_NAME = 'YOUR_TABLE'; - 如果查不到记录，不是策略没写对，而是 Heat Map 根本没攒够数据 —— 别急着调 ILM
创建 ILM 策略时，MOVE PARTITION 必须显式指定目标表空间
Oracle 不会猜你要挪到哪，TIER TO 后面必须跟真实存在的表空间名，且该表空间必须已预创建、有足够空间、且用户有 QUOTA：
- 错误写法：
TIER TO cold_storage（cold_storage是别名或未创建的表空间名 → 报错ORA-43853） - 正确写法：
TIER TO ts_cold（ts_cold是已存在且可写的表空间） -
MOVE PARTITION操作会重建本地索引，全局索引需手动UPDATE INDEXES或重建，否则失效 - 策略中若含
COMPRESS FOR ARCHIVE LOW，要确保目标表空间支持压缩（ASSM+SEGMENT SPACE MANAGEMENT AUTO）
ILM 调度和执行时机容易被误解
ILM 不是“一定义就跑”，它由后台进程 ILM_RUN 触发，且只在维护窗口（Maintenance Window）内执行，默认每天凌晨 2:00–6:00，且受 DBMS_ILM.SCHEDULE_JOB 控制：
- 检查当前窗口状态：
SELECT WINDOW_NAME, ENABLED FROM DBA_SCHEDULER_WINDOWS; - 手动触发一次：
EXEC DBMS_ILM.EXECUTE_ILM(ilm_scope => DBMS_ILM.ILM_SCOPE_SCHEMA); - 策略匹配条件是“段级最后访问时间”，不是分区键值 —— 所以即使你按
createdTime分区，ILM 仍按HEAT_MAP记录的LAST_ACCESS_TIME判断冷热 - 迁移发生后，
DBA_TAB_PARTITIONS.READ_ONLY不会自动变YES，得自己加MODIFY PARTITION ... READ ONLY来锁住冷分区
元数据刷新延迟导致误判
ILM 执行完 MOVE PARTITION 后，DBA_SEGMENTS.BYTES 和 BLOCKS 可能几分钟内不更新，但 DBA_TAB_PARTITIONS.TABLESPACE_NAME 和 READ_ONLY 是即时生效的：
- 别用
SELECT SUM(BYTES) FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'ts_cold'立刻验证迁移结果 - 应查：
SELECT PARTITION_NAME, TABLESPACE_NAME, READ_ONLY FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'YOUR_TABLE'; - 压缩是否生效，看
COMPRESSION字段，不是看BYTES缩没缩
ILM 自动化最脆弱的一环，不在策略语法，而在表空间、权限、索引、只读状态这些“周边配置”——少配一项，策略就静默失败，日志里只留一句 no qualifying segments，根本看不出哪错了。
