ADO是基于热图的本地存储优化策略，仅支持同库内自动压缩（COMPRESS FOR OLTP/BASIC）和表空间迁移（MOVE TO），不支持跨库、跨实例或异构环境的数据迁移。
Oracle 19c 中没有 ADO 策略能直接实现“段的自动压缩与迁移”——ADO（Automatic Data Optimization）只支持自动压缩（COMPRESS）和自动分层（MOVE 到不同表空间），但不支持跨数据库、跨实例或异构环境的“迁移”。 它是存储层策略，不是数据迁移工具。混淆这点会导致配置无效、任务静默失败或误以为数据已“迁出”。
什么是 ADO 及其在 19c 中的实际能力
ADO 是基于 Heat Map（热图）统计访问模式后触发的策略引擎，依赖两个关键组件：DBMS_HEAT_MAP 启用热图、DBMS_ILM 定义 ILM（Information Lifecycle Management）策略。它只能对本地数据库内的段（如表、分区）执行以下操作：
-
COMPRESS FOR OLTP或COMPRESS BASIC：需目标表空间支持混合列压缩（Hybrid Columnar Compression）且为 ASSM 管理；普通本地表空间仅支持BASIC压缩 -
MOVE TO tablespace_name：仅限同库内表空间切换（例如从USERS移到TBS_ARCHIVE），不能指向远程库、GoldenGate 目标端或达梦/金仓等异构库 - 所有动作都在维护窗口（
MAINTENANCE_WINDOW_GROUP）内由MMON进程触发，非实时
配置 ADO 前必须确认的 4 个前提条件
缺一不可，否则 ADD_POLICY 报错或策略永不生效：
- 数据库级热图必须启用：
ALTER SYSTEM SET HEAT_MAP = ON;（重启后持久化） - 目标表空间必须为
ASSM（自动段空间管理）：SELECT tablespace_name, segment_space_management FROM dba_tablespaces;—— 非 ASSM 表空间无法执行MOVE - 用户需有
EXECUTE权限 onDBMS_ILM和DBMS_ILM_ADMIN - 表必须启用行移动：
ALTER TABLE sales ENABLE ROW MOVEMENT;（MOVE操作必需）
一个可验证的 ADO 压缩+分层策略示例
假设有一张按时间分区的销售表 sales，希望 90 天未访问的分区自动压缩并移入归档表空间 TBS_ARCHIVE：
DECLARE
policy_name VARCHAR2(128);
BEGIN
policy_name := DBMS_ILM.CREATE_ILM_POLICY(
policy_name => 'sales_ilm_policy',
condition => DBMS_ILM.MOVETODATAFILE('TBS_ARCHIVE')
AND DBMS_ILM.COMPRESSFOROLTP(),
schedule => NULL,
enabled => TRUE
);
END;
/注意：MOVETODATAFILE 实际调用的是 MOVE，不是导出/导入；若 TBS_ARCHIVE 不在同库中，该策略会卡在 PENDING 状态，SELECT * FROM dba_ilmobjects 可查状态。Oracle 不报错，但也不执行。
真正需要“迁移”时该用什么替代方案
如果业务场景本质是把冷数据从生产库迁到历史库（如 Oracle 到 Oracle、Oracle 到金仓、Oracle 到达梦），ADO 完全不适用。此时应切换技术栈：
- 同构迁移（Oracle → Oracle）：用
expdp+impdp配合QUERY和REMAP_TABLESPACE，或用DBMS_CLOUD导出到对象存储再导入 - 信创迁移（Oracle → 金仓/达梦）：启用金仓的
compatibility_mode = 'oracle'，用 KES 迁移工具做语法+类型映射；达梦用 DTS 工具评估后执行结构+数据同步 - 持续增量迁移：用 Oracle GoldenGate 或 OCI Database Migration 的 CDC 模块捕获变更，而非依赖 ADO 的离线批处理
ADO 的边界很清晰：它管“数据在本库内怎么存得更省”，不管“数据要去哪”。把压缩策略配得再精细，也不会让一行数据自己飞到另一个实例里。
