oci database migration 是一套调度器，自动调用 data pump、goldengate 和 cloud premigration advisor tool 执行注册、连通检测、字符集比对及基础对象迁移；但序列校准、物化视图刷新、dblink 配置需半自动干预，pl/sql 硬编码路径、utl_file 调用等完全不处理。
能平滑迁移，但“平滑”不等于“无感”——关键取决于你是否在迁移前就识别出那几个必须手动干预的环节，而不是等 OCI Database Migration 控制台显示“验证通过”就以为万事大吉。
OCI Database Migration 服务到底能自动做什么？
它不是黑盒搬运工，而是一套调度器：自动调用 Data Pump 做逻辑导出导入、调用 GoldenGate 做联机增量同步、用 Cloud Premigration Advisor Tool 扫描兼容性问题。但它不会替你改 CONNECT BY 查询里的伪列引用，也不会帮你重写调用了 UTL_FILE 的存储过程。
- 自动完成：数据库注册、网络连通性检测、字符集比对、基础对象（表/索引/约束）结构迁移
- 半自动依赖人工：序列起始值校准、物化视图刷新策略调整、DBLink 目标地址重配
- 完全不碰：PL/SQL 中硬编码的路径、
DBMS_OUTPUT.PUT_LINE日志输出逻辑、自定义 UTL 包封装
本地 Oracle 到 OCI 的网络和权限准备最容易翻车
OCI 不允许源库直接暴露公网 IP，也不接受从本地发起的反向连接。你得提前在本地防火墙、OCI 安全列表、OCI 网关路由三处同时开白名单，且端口必须严格对应。
- 源库监听端口（默认
1521）需在本地防火墙放行，并确保 OCI VCN 的安全列表中入方向规则允许该端口 + 源 CIDR - OCI 目标数据库必须启用
tnsnames.ora中配置的 SERVICE_NAME，不能只靠 SID 连接；否则OCI Database Migration会卡在“测试连接”步骤报ORA-12514 - 用于迁移的数据库账号必须有
EXP_FULL_DATABASE和IMP_FULL_DATABASE角色，仅DBA不够——这是很多 DBA 忽略的细节
脱机 vs 联机迁移的选择，本质是业务容忍度问题
别被“Zero Downtime Migration”名字迷惑。所谓零停机，是指应用层可读写，但目标库在最终切换前始终是只读状态，且中间存在秒级数据延迟。如果你的业务要求强一致性（比如账务核心），就必须接受一次可控的停机窗口。
- 选脱机迁移：适用于夜间批处理系统、报表库、测试环境；耗时短，失败回滚快；但需要完整停机窗口，且
Data Pump导出文件需存到 OCI Object Storage，注意 bucket 权限策略 - 选联机迁移：适用于交易类系统；依赖
GoldenGate抽取源库 redo log，要求源库开启归档模式（ARCHIVELOG）且FORCE LOGGING已启用；否则增量同步会静默失败 - 混合方案更常见：先用脱机迁移主干数据，再用联机补增量，最后在业务低峰期执行最终切换——这需要你在
OCI Database Migration控制台里手动触发“Final Cutover”按钮，而非让它自动执行
迁移后最常被忽略的三件事
迁移完成 ≠ 上线成功。OCI 上的 Oracle 数据库默认关闭了部分本地常用功能，且监控方式完全不同。
-
V$SESSION和V$SQL视图仍可用，但 OCI 自治数据库（如 ATP/ADW）不开放这些视图；如果你用的是 Base Database Service（VM 方式），则需确认是否启用了STATISTICS_LEVEL = ALL，否则 AWR 报告为空 - 本地写的备份脚本（
RMAN脚本调用BACKUP DATABASE PLUS ARCHIVELOG）在 OCI 上基本失效——OCI 自动管理备份，你只能通过控制台或oci-cli查看保留策略，不能手动触发物理备份 - OCI 的
tnsnames.ora默认使用连接池（CONNECTION POOLING），而本地直连习惯容易导致应用连接数突增超限；建议上线前在应用侧显式配置maxPoolSize，并观察 OCI 监控中的Database Connections指标
