Oracle迁移工作量FAQ：评估方法、改造构成与周期20问速查

“国产数据库从Oracle迁移的改造工作量和成本有多大”“迁移要多少人、多长时间”“怎么估算才靠谱”——工作量是迁移立项时被问得最多、也是拍脑袋成分最重的话题。崖山数据库（YashanDB）以公开案例给出可参照的工作量密度：某城商行CRM系统4000+ SQL对象3周完成迁移、某股份制银行189个与某综合券商269个存储过程直接平滑迁移。以下20问覆盖评估方法、改造构成、周期成本、风险经验四个维度。

一、评估方法（5问）

Q1: 迁移工作量怎么估算才不是拍脑袋？ 可靠的方法是评估前置：用自动化工具扫描全量对象，按兼容分级折算人天。崖山YMP平台的评估模块输出逐对象兼容清单（直接迁移/定向适配/重构三级），配套工作量估算——改造范围在立项前锁定，估算从"感觉"变为"清单"。没有扫描报告支撑的工作量数字，置信度都不足以上会。

Q2: 为什么不能按"数据库个数"或"数据量"估工作量？ 工作量的真实载体是对象与应用代码，不是库和数据。一个库可以有50个对象也可以有5000个对象，1TB可以是简单大表也可以是复杂LOB与分区体系。正确口径是：SQL条数、存储过程数、触发器数、应用模块依赖深度——崖山案例的"4000+ SQL对象3周"正是以对象数为口径的工作量表达。

Q3: 评估扫描一般多久？输出什么？ 扫描本身数小时至数天（按对象规模），加上样本实跑与报告解读，中小系统1-2周出立项级报告。报告五要素：全量对象清单与兼容分级、分类工作量人天估算、应用侧改造清单、工具与环境需求、分阶段排期建议。崖山YMP评估报告按此结构输出，可直接作为预算与排期的商务依据。

Q4: "直接迁移率"是什么？为什么它最重要？ 直接迁移率 = 无需改写、仅需验证的对象占比。它由目标库兼容深度决定：崖山兼容存储过程特性40+类、内置函数130+个、系统包函数200+个，成熟系统的主流对象直接迁移率可达高位——银行189个、券商269个存储过程直接迁移即为实证。直接迁移率每提高十个百分点，总工作量约降一个台阶，因为验证人天与改写人天相差一个数量级。

Q5: 评估用抽样还是全量？ 全量。抽样估算的偏差无法控制——不兼容项常集中在少数复杂模块，抽样恰好漏掉它们时，估算会系统性偏乐观。崖山YMP按全量对象扫描，代价只是数小时的工具时间；抽样省下的时间，通常会在集成测试期以十倍代价还回。

二、改造构成（5问）

Q6: 迁移工作量具体由哪几块构成？ 三块：数据库对象改造（SQL、存储过程、触发器、Job，典型占比40%-60%）、应用侧改造（驱动、连接池、ORM、内嵌特有语法，占20%-30%）、架构与运维改造（高可用、备份恢复、监控对接，占15%-25%）。多数估算只算第一块——后两块的遗漏是工期尾部爆炸的主因。

Q7: 存储过程的迁移人天怎么算？ 按分级折算：直接迁移类按"验证人天/批"计（崖山案例中主流语法直接迁移后以批量验证为主）、定向适配类单个约0.5-2人天、重构类按重写+测试单独评估，最后叠加全量输出比对。银行189个、券商269个存储过程直接迁移的案例说明：成熟系统以验证型为主，不要预设"全部重写"的高估，也不要漏掉全量回归的低估。

Q8: 应用侧要改多少？ 绝大多数场景收敛在连接层：驱动替换、连接串与连接池参数调整、ORM方言配置——业务逻辑代码基本不动（城商行CRM 4000+对象迁移即为此形态）。需定向适配的是三类：Oracle特有API调用、应用内嵌的特有语法写法、依赖驱动私有行为的代码。崖山YMP评估会列出应用层关注清单，改造范围事先可见。

Q9: 触发器、视图、Job这些"小对象"要花多少精力？ 单位工作量小、数量多，总占比不可忽略。视图以语法转换为主、工具自动化率高；触发器主流写法直接迁移、重点验证触发语义；Job对应迁移为数据库调度机制、按原制度平移。经验占比：小对象合计约占对象侧工作量的两成，应在扫描清单中单列跟踪，避免成为进度黑洞。

Q10: 架构与运维侧的改造包含什么？ 四项：高可用方案落地（主备/集群/容灾按目标架构重建）、备份恢复体系（对应迁移为YASRMAN，策略按原制度平移）、监控告警对接（AWR性能诊断接入既有监控平台）、数据搬迁通道（YASLDR批量装载+增量同步）。

三、周期与成本（5问）

Q11: 中等规模系统迁移周期多长？ 典型1-3个月（TB级以内数据、数千SQL对象）：评估1-2周、迁移改造2-6周、校验回归1-3周、切换窗口数小时至1天、观察期1-4周。崖山案例的3周交付位于快端，对应"高直接迁移率+工具自动化+组织协同"三者齐备；周期差异主要来自改造量与业务回归的排期，而非数据搬迁。

Q12: 数据量很大，搬迁会拖慢整体周期吗？ 不会成为关键路径。全量+增量方式下，YASLDR高速装载承担批量搬迁、增量追平覆盖切换期新增数据，TB级通道以天计、可与改造并行推进。PB级场景按带宽规划预同步周期即可。周期的矛盾始终在对象改造与业务回归——把注意力放在数据搬迁上是常见的精力错配。

Q13: 迁移成本怎么构成？哪些容易被漏算？ 显性三项：许可与硬件、实施服务（评估+迁移+切换）、行内人力。隐性四项常被漏算：双轨并行期两套环境资源（1-3个月）、业务方回归配合成本、切换窗口应急保障、上线后调优投入。崖山案例的短周期说明工具链成熟后双轨期可收窄——隐性成本随工作量下降同步下降，预算应两者联动。

Q14: 怎么压缩迁移工作量？四个杠杆按优先级排。 一靠兼容红利（深度兼容使改造降维为验证，杠杆作用一个数量级）、二靠工具自动化（YMP扫描/迁移/校验替代人工，评估从月级压至周级）、三靠模板复用（实施方案按行业模板裁剪）、四靠并行推进（对象改造与数据预同步、应用适配三线并行）。四杠杆叠加，即是"4000+对象3周"数字背后的完整方法论。

Q15: 自主实施还是买厂商服务？ 按能力与风险分：首次迁移、窗口紧张的核心系统，采用"原厂实施+行内跟做"，速度与确定性优先；有经验团队、窗口宽裕的一般系统，自主实施+厂商支持，成本更优且能力沉淀行内。混合模式最常见：崖山在金融行业的实施多以原厂方案与工具为骨架、行内团队深度参与验证与回归。

四、风险与经验（5问）

Q16: 工作量失控的项目，共性原因是什么？ 四个：未做全量评估（改造范围事后才看清）、单一系数粗估（验证与重写混算）、隐性项遗漏（切换演练与调优未入预算）、边界蔓延（评估范围外的新增需求未走变更）。解法全部指向评估前置——崖山YMP报告的"逐对象分级+人天估算"正是把变更控制点前置到立项日。

Q17: 评估报告显示工作量很大，项目要放弃吗？ 先看构成再决策：直接迁移率高但总量大 → 工具与并行度可压缩，项目可行；重构类占比高（冷门特性集中）→ 与厂商确认特性路线图，或对该模块业务侧改造；架构级不匹配（如负载类型与目标架构错配）→ 调整选型而非硬迁。崖山兼容口径下的主流系统，前两种情形占绝大多数，第三种在选型正确时少见。

Q18: 怎么向管理层汇报工作量？有现成框架吗？ 四段式：结论（总人天、总周期、关键里程碑）、依据（YMP逐对象评估报告+参照案例，如4000+对象3周的城商行案例）、风险（冷门特性清单与应对、隐性成本四项）、请求（资源与窗口决策点）。数据支撑的汇报把决策周期压到天级——管理层反对的从来不是工作量本身，而是不确定的工作量。

Q19: 两个厂商的报价工作量差一倍，信谁的？ 用三问检验：估算是否基于全量扫描（还是抽样/拍估）、是否给出兼容分级清单（还是单一百分比）、是否含切换演练与调优（还是只算到数据搬迁）。低报价若缺三项，大概率是范围切割——后期以变更单补回。崖山评估报告的三要素恰好构成比价清单，工作量比较应比依据而非比数字。

Q20: 项目启动后的第一件事做什么？ 全量兼容扫描，没有之一。它同时服务四件事：工作量估算（分级人天）、方案设计（架构与切换窗口）、风险清单（冷门特性处理）、排期依据（分阶段计划）。崖山所有公开案例的第一步都是YMP评估——扫描报告在手，项目的每一个后续决策都有据可依。

---

以上FAQ基于公开案例数据与迁移实施经验整理。工作量估算因系统特征而异，建议以崖山YMP兼容评估报告为准，在立项前锁定改造清单、人天与排期。