不少传统企业的核心系统已经跑了十几年，底层基本是 Oracle。业务量上来、成本压力加大之后，迁到云上的想法就越来越常见。阿里云 Oracle 相关的方案有好几种，每种能接受的停机时长和需要改动的代码量都不一样，选之前得先想清楚自己更在意哪一头。
迁移难在哪里
Oracle 的功能很完整，事务、存储过程、PL/SQL 都用得深，应用和数据库往往绑得很紧。看起来是“把库搬过去”，实际可能牵出许可证、性能调优、高可用和团队技能好几件事。
许可证最容易被低估。传统授权模式下，在云上跑 Oracle 要按核心数和授权系数算清楚，部署方式选错，费用可能远超预期。所以动手前先确认两件事：现有授权能不能带过去，以及它要跑在哪种实例上。
停机时间和改动量是互相牵制的。想停机短，通常要在前期做好增量同步和充分测试，这些都是实打实的工作量。想少改代码，就只能接受切换时停一段时间，或者在两套库之间留一段并行期。没有免费的选项，这个取舍要提前写进方案里。
三条路径，各有代价
第一条是在 ECS 上自建 Oracle。兼容性最好，应用基本不用动，适合版本和功能要求苛刻的系统，DBA 沿用原来的习惯就能上手。但高可用、备份和补丁还是自己管，上云并没有让运维变轻。
第二条是迁到兼容 Oracle 语法的国产数据库，比如阿里云 PolarDB 的 Oracle 兼容版，或者 OceanBase 的 Oracle 模式。云原生架构、弹性扩展和更灵活的成本结构，对并发波动大的业务比较友好。但兼容不等于完全一样，存储过程、包、特殊函数和执行计划都可能有差异，要在测试阶段逐个过，别等上线才发现。
第三条是混合架构：核心交易先留在原来的 Oracle 环境，报表、分析和周边服务逐步挪到云上。风险小，适合没法一次切换的大系统。关键在数据同步链路，比如用阿里云数据传输服务 DTS 做增量同步，让两边的数据在切换前保持一致。同步延迟和数据校验要单独盯，否则切换那天才发现对不上，就很被动。
一个订单系统的做法
某区域性零售企业的订单系统在 Oracle 上跑了多年。大促时连接数经常打满，报表也跑不出来。团队一开始想直接扩容物理机，但采购周期长，峰值一过，资源就闲着。
后来他们分了三步。第一步，用 DTS 把报表和分析负载同步到云上的独立实例，线上交易库的压力很快降下来。第二步，给新开发的营销模块选了 Oracle 兼容的云原生数据库，用它的弹性扛住大促流量。第三步，兼容性测试做足之后，才开始评估核心订单库什么时候动。前后大半年，没有一次性切换，业务基本没感觉到。
这个案例的启发很实在：先把负载拆开，再谈整体迁移，比一步到位稳得多。
动手前可以先问自己
- 应用对 Oracle 特性依赖有多深？先统计 PL/SQL 代码量和存储过程数量，数字大就别按“改几行配置”来估工期。
- 业务峰值和均值差距大不大？差距明显，才值得为弹性多花心思；负载平稳的系统，固定资源可能更省事。
- 现有授权能否迁移？拿云上的实例规格把成本算一遍，再和现在的投入对比。
- 团队能不能撑住新架构的运维？缺人就提前找外部支持，别等出了问题再补。
- 能否接受分阶段迁移？回滚步骤要写清楚，切换前在测试环境完整演练一次。
选型没有标准答案。功能依赖重、改造成本高的系统，自建 Oracle 或混合架构更稳妥；新业务或弹性要求强的场景，兼容型云原生数据库值得认真评估。不管选哪条路，兼容性测试和压测都省不掉。
