oracle11g迁移到人大金仓v9前的准备和分析

Oracle 11.2.0.4 → KingbaseES V9 迁移风险分析证据等级：已验证= 知识库条目结构与公开手册内容可直接对应；推断= 由产品机制与条目 LAB 设计推导；未验证= 未取得原文，需在对应手册中核对。目标端版本基线：KES V9（V009R001C002B0014）；迁移工具线：KDMS / KDTS(KDTS-PLUS) / KFS(FlySync V2R2) / KReplay。条目正文不可直接抓取，本文只给条目定位与操作思路，参数默认值、语法细节以官方手册为准。一、结论先行Oracle 11g 迁 KES不是"工具跑一遍"的事，成败取决于三件前置工作：兼容模式选定、KDMS 评估出的改造清单、KFS 双轨回退能力。这三件里任何一件放到割接当天才做，项目基本必翻。已验证11.2.0.4 属常见源端，知识库迁移课程的实验基线就是Oracle 11g（02-软硬件环境选型-01-Oracle安装和调优的 LAB02 即图形化安装 Oracle 11g），因此工具链对 11g 有对应路径；但具体参数、数据类型映射仍要按《Oracle 至 KingbaseES 迁移最佳实践》与《KingbaseES 与 Oracle 的兼容性说明》逐项核对。已验证高风险集中在四处：PL/SQL 与 Oracle 专有对象改造、SCN 一致性点与归档、增量同步的连接器/补充日志条件、割接当天的比对与回退。推断迁移方法论的官方骨架是六阶段：迁移信息搜集 → 软硬件环境选型 → 沙盘演练 → 割接上线 → 容灾备份 → 运维保障。已验证常见失败模式是把第三阶段"沙盘演练"当成"迁完就完"——它必须同时产出可重复的迁移脚本、性能对比报告、应用验证结论、回退方案，第四阶段割接评审正是查这些产物。推断二、可以提前规划、避免踩坑的部分这一节是"现在就能做、做了能省掉后面大麻烦"的清单。#提前动作为什么必须提前证据1先跑KDMS 迁移评估（采集器 → 采集 Oracle 对象定义 → 在线评估 → 出改造清单）用它决定是否启用 Oracle 兼容模式、哪些 PL/SQL 必须改写；拍脑袋定改造范围是最大浪费已验证2安装 KES 时就选定 Oracle 兼容模式兼容模式直接决定 PL/SQL 与 SQL 改动量；事后切换代价高，等于重来推断3源端 Oracle 侧准备：开归档、确定 SCN 一致性点、确认归档保留足够KDTS 基于 SCN 迁移，增量同步（KFS）从这个位点接续；归档丢了就没有一致性起点已验证4源端按