软件定制开发中 Oracle 迁移 PostgreSQL：Gemini 辅助与 3 个坑

某制造企业 300+ 存储过程、47 个触发器，从 Oracle 11g 迁到 PostgreSQL 16。我们原计划纯手工 12 周，最终用 Gemini 辅助转换加人工校验，7 周上线——但触发器有约 30% 需要重写。这篇把周期、能力边界和踩过的坑拆开讲，给准备做软件定制开发或数据库迁移的团队一个参照。

2026 年，企业为什么还在迁 Oracle→PostgreSQL

迁移不是一个新话题，2026 年仍在持续。三个原因叠加：第一是许可成本，Oracle 按 CPU 核收费，很多企业一套核心系统每年许可费就是百万级；第二是云原生，PostgreSQL 在主流云厂商都有托管实例，扩缩容、备份、高可用都是开箱即用；第三是 AI 扩展生态，pgvector、pgai 这类扩展让 PostgreSQL 成了 AI 应用的首选关系库。

PostgreSQL 官方在 2026 年 7 月发布 19 Beta 2，18 版本已通过 SQL:2023 Core 规范 177 项强制特性中的 170 项——这是目前所有关系型数据库里最高的合规水平。它不是"够用"的开源替代品，而是长期维护、近 40 年持续演进的系统。

成本账不只在数据库许可这一项。AI 模型降价正在改写软件定制开发的交付公式，如果你在重新评估技术栈和供应商结构，可以对照我们关于软件定制开发报价崩塌：AI 模型降价 50% 后的交付公式的分析。

Gemini 代码转换的能力边界：函数语法能转，业务逻辑转不了

2026 年 Google Cloud 的 Database Migration Service 加入了 Gemini 驱动的 AI 辅助代码转换，可以把 Oracle / SQL Server 的存储过程、触发器、自定义函数批量转成 PostgreSQL 的 PL/pgSQL。方向是对的：数据库迁移里最费人力的就是 PL/SQL 存量代码，纯手工翻译一个中型系统要数周。

但用下来要分清两层。语法层，循环、条件、异常处理、游标写法，Gemini 转得不错，能大幅缩短机械翻译时间。语义层，Oracle 的包（PACKAGE）状态、隐式类型转换、业务规则，它转不了——这些需要人理解业务后重写。我们把它定位成"翻译器"而不是"重构器"：翻译交给 AI，重构和校验留给人。

同样的分工也出现在编码环节。AI 并行编码让团队规模问题被重新讨论，相关判断可参考软件定制开发新分工：300 个 AI 并行编码，企业还需要外包团队吗。

一个 300+ 存储过程迁移项目的周期对比

方案	转换阶段	校验/返工阶段	总周期	说明
纯手工	8 周	4 周	约 12 周	全人力，PL/SQL 熟练工程师 2 名
AI 辅助直接收	5 周（机器转换）	7 周（大量返工）	约 12 周	约 40% 代码需返工，隐藏成本高
AI 辅助 + 人工校验（混合）	3 周	4 周	约 7 周	先依赖图后转换，触发器重点手改

三个数字值得记：纯手工 12 周、AI 直收并不快（返工吃掉收益）、混合方案 7 周。AI 的价值不在"一键完成"，而在把转换阶段从 8 周压到 3 周，让人力集中在真正需要判断的地方。

兼容性测试清单：5 类问题最容易被忽略

转换完成不等于迁移完成。我们按下面清单过一遍，每个都踩出过线上事故：

• 隐式类型转换：Oracle NUMBER 与 PostgreSQL numeric 的精度和舍入差异，金额字段必须逐列核对。
• 包与序列：Oracle SEQUENCE、PACKAGE 全局变量没有一一对应物，要用 PostgreSQL 的 IDENTITY / 临时表方案重设计。
• 游标语义：FOR UPDATE、游标变量在两种数据库的锁定行为和返回顺序不同，分页逻辑最容易翻车。
• 异常与事务：Oracle 的 RAISE、自治事务与 PL/pgSQL 的 RAISE EXCEPTION、SAVEPOINT 语义有差异，存储过程内事务边界要重新画。
• 字符集与排序：CLOB 对应 TEXT、NCHAR 对应 VARCHAR，排序规则（collation）影响索引和查询结果，测试阶段必须覆盖中文排序。

每条对应一段可复现的回归用例，上线前全部跑绿，才允许切流量。

反面教训：触发器 30% 需手改，依赖关系图必须先做

先说结论：自动转换的触发器约 30% 需要手改。我们项目里 47 个触发器，Gemini 转完直接能用的只有约 32 个，剩下 15 个涉及 :NEW/:OLD 语义、同表 UPDATE 触发级联，机器生成的 PL/pgSQL 会死循环或行为不一致，只能重写。

更大的教训是顺序。我们一开始没做依赖关系图，直接按文件批量转，结果 3 个核心包互相引用，转出来的代码函数签名对不上，返工浪费了一周。正确顺序是：先建依赖关系图 → 再迁表结构 → 再转函数/存储过程 → 再处理触发器 → 最后做全量数据校验。依赖不清，AI 转得越快，错得越整齐。

这套顺序也适用于没有 AI 辅助的传统迁移，只是人工模式容易在转换阶段就发现依赖问题，AI 模式把问题集中爆发到了校验阶段。

常见问题

Oracle 迁移 PostgreSQL 一定省钱吗？

多数场景省，但不是必然。许可费会下降，但迁移、重写、团队学习成本是一次性投入。存量 PL/SQL 越多、业务逻辑越绕，迁移成本越高，先做评估再决策，别只看 License 账单。

Gemini 辅助转换能完全替代 DBA 吗？

不能。它替代的是"机械翻译"环节，替代不了兼容性测试、性能调优、数据一致性校验。我们项目中 DBA 的角色从写 PL/SQL 变成审 AI 输出 + 设计回归用例，人还是需要，但数量可以减少。

迁移周期一般多久？

取决于存量代码规模和数据量。100 个存储过程以内的小系统，混合方案 3-4 周；300+ 存储过程的中型系统，7 周左右；带数据仓库和实时同步的大型系统，通常按月计，还要加并行运行期。先跑一次依赖分析和代码量评估，周期才能估准。

做迁移评估需要准备什么？

一份库表清单、一份存储过程/触发器数量统计、一次依赖关系草图就够了。评估输出通常包括成本边界、风险清单和分阶段迁移路径，不需要先买工具或签合同。

参考

PostgreSQL 官方项目介绍（含 19 Beta、SQL:2023 兼容度、特性清单）：https://www.postgresql.org/about/

如果你的系统正在考虑从 Oracle 迁到 PostgreSQL，或已经卡在某个兼容性问题上，可以把现有库表清单和存储过程规模发给我们做一次迁移评估——先算清楚成本边界，再决定怎么动。联系入口在 /contact，同类交付记录见 /cases。如果还在纠结整体交付模式，软件定制开发 2026：自研还是外包的三个决策框架可以作为第一步参考。