26 深入专题：Oracle 兼容与迁移

Oracle 兼容特性、迁移评估与去 O 实践。

Alien 转换 rpm 到 deb 安装包在 PG 环境里有什么用？

alien 是一个把 rpm 转成 deb（或反向）的安装包转换工具。在 PG 生态里，很多第三方工具、插件、客户端只提供 rpm 包（面向 RHEL/CentOS 系），而目标服务器是 Debian/Ubuntu 系（只用 deb），此时可用 alien 转换后安装。不过 alien 转换的包可能缺少依赖关系处理，生产环境更推荐用对应发行版源里原生打包的 PG 及插件。

Babelfish 如何让 PostgreSQL 兼容 SQL Server？

Babelfish 是 AWS 开源的 SQL Server 兼容层，跑在 Aurora PostgreSQL 上，让应用用 T-SQL 方言和 SQL Server 协议连到 PG。它有 single-mode（整个库只讲 T-SQL）和 multi-mode（同一实例里 PG 库和 T-SQL 库共存）两种模式。Babelfish 把 T-SQL 解析翻译成 PG 内部结构，兼容数据类型、语法、系统视图，用于 SQL Server 迁移到 PG 场景，大幅降低迁移改写量。

EDB PPAS/EPAS 的 Oracle 兼容思路是什么？

EDB 的 PPAS（后改名 EPAS，Postgres Advanced Server）是商业级 Oracle 兼容数据库，在 PostgreSQL 内核上实现了 Oracle 的 PL/SQL、内置包、数据类型、SQL 语法、sqlplus 兼容客户端等，目标让 Oracle 应用『近乎零修改』迁移。EDB 提供 EDB*Plus 兼容 sqlplus 的命令行工具，还有兼容 Oracle 的 PL/SQL 引擎。它是商业化去 O 方案里兼容度最高的代表之一，代价是闭源收费。

IvorySQL 是什么，它如何做 Oracle 兼容？

IvorySQL 是瀚高开源、基于 PostgreSQL 的 Oracle 兼容数据库，把 Oracle 的 PL/SQL 语法、内置包、数据类型等兼容能力以开源方式提供。它吸收 orafce 等兼容思路，目标是让 Oracle 用户能以较低成本迁移到 PG 体系。作为开源 Oracle 兼容产品，它填补了『开源 + 较强 Oracle 兼容』的空缺，与 EDB（闭源）形成对照。

KingbaseES KFS 迁移 Oracle 的全量+增量同步怎么做？

KingbaseES（人大金仓）提供 KFS 迁移工具，先做全量数据搬迁，再通过增量同步（解析 Oracle redo 或触发器捕获）持续追平源库，最后在业务低峰期做切换，实现 Oracle→KingbaseES 的平滑迁移。实操手册强调迁移前做兼容性评估、类型映射、对象转换（存储过程/触发器/序列），迁移后做 count/hash 一致性校验和性能基线对比，再灰度切流。

Oracle 与 PostgreSQL 的概念术语对照里最关键的差异是什么？

最关键的差异：Oracle 的『数据库=实例+库』概念里，实例（instance）与数据库（database）分离，一个实例对应一个库；而 PG 一个实例（cluster）可包含多个 database。Oracle 的 schema 等同于用户（user=schema），PG 的 schema 是 namespace、与用户解耦。Oracle 表空间（tablespace）与 PG 的表空间语义也不同。理解这些术语差异是去 O 迁移、对象映射和权限设计的前提。

Oracle 的 pljson 与 PG 原生 JSON 能力如何对应？

Oracle 用 pljson 包处理 JSON，PG 原生就内置强大的 JSON 能力（json/jsonb 类型、jsonpath、丰富函数），去 O 时无需再依赖 pljson 这类第三方包。PG 的 jsonb 支持索引（GIN）、jsonpath 类似 XPath 的路径查询，能力上覆盖并超出 pljson。迁移时把 Oracle 的 pljson 调用改写成 PG 原生 JSON 函数即可，反而更简洁高效。

PG 与 Oracle 在 storage/segment/tablespace 上的概念差异是什么？

Oracle 用表空间（tablespace）组织数据文件，数据文件按 segment（段）管理，表/索引对应不同 segment；PG 的表空间只是存储目录，表和索引都放进对应表空间目录下，没有 Oracle 那么细的 segment/数据文件层级。理解这个差异有助于迁移时规划存储：Oracle 的多个 datafile/segment 在 PG 里简化为目录+文件，容量管理和备份策略要相应调整。

PG 如何兼容 MySQL 的 bit(n) 用法？

MySQL 的 bit(n) 在超出范围时按位填充 1 等行为与 PG 原生 bit 类型不完全一致，PG 兼容 MySQL bit(n) 需要处理其特殊的溢出/填充语义。PG 有 bit varying 和 bit(n) 类型，但边界行为不同，迁移 MySQL 时要做类型映射和行为校验，必要时用函数模拟 MySQL 的位运算习惯。这提醒异构迁移不能只改类型名，还要验证边界行为一致性。

PG 如何兼容 MySQL 的 order by 拼音或 binary 排序？

MySQL 可用 GBK/utf8 的 collation 或 binary 关键字控制按拼音、按字节排序。PG 通过设置不同的 collation（如 zh_CN、C locale）和 lc_collate 参数控制排序规则，用 C collation 得到按字节的 binary 排序。去 MySQL 迁移时，要把 MySQL 的 collation 语义映射成 PG 的 collation，才能保证 order by 结果与原来一致，避免中文字段排序结果漂移。

PG 如何兼容 MySQL 的『指定位置加列/修改列位置』？

MySQL 支持 ALTER TABLE … ADD COLUMN x AFTER y 等指定列位置操作，PG 原生不支持列位置调整（列顺序由系统表 attnum 决定，逻辑上无关紧要）。PG 兼容方式是用 CREATE TABLE AS 重建或插件模拟列位置语义，但本质上 PG 通过列名而非位置引用，迁移时应改造 SQL 用列名而非位置。这是 MySQL→PG 迁移常见的不兼容点。

PG 如何兼容 Oracle 的 binary_float/binary_double？

Oracle 有 binary_float、binary_double 两种二进制浮点类型（近似值、运算快、精度略低）。PG 对应使用 real（4 字节浮点）和 double precision（8 字节浮点），语义基本对应。去 O 迁移时把 binary_float→real、binary_double→double precision 映射即可，注意两者都是近似存储，等值比较可能因精度差异有细微不同，迁移需评估对账逻辑。

PG 如何兼容 Oracle 的 sqlplus 变量和交互式用法？

Oracle 的 sqlplus 支持 & 变量替换、DEFINE、ACCEPT 等交互式特性，PG 的 psql 有对应的 :变量、\set、\prompt 机制，但语法和交互行为不同。去 O 迁移时要把 sqlplus 脚本里的 &var 改成 psql 的 :var，把 DEFINE 改成 \set，交互输入用 \prompt 模拟。EDB 的 EDB*Plus 则直接兼容 sqlplus 语法，可减少脚本改写。

PG 如何兼容 SQL Server 的大小写不敏感（CI）？

SQL Server 默认排序规则大小写不敏感，PG 默认大小写敏感。PG 兼容 CI 有几种方式：用 citext 类型存字符串、建函数索引对列 lower()、或使用大小写不敏感的 collation。citext 是官方推荐的 CI 文本类型，比较时自动忽略大小写，最接近 SQL Server 行为，适合 SQL Server→PG 迁移中需要保持原有 SQL 不因大小写改写的场景。

PG 的 clone schema 如何实现，去 O 有什么用？

PG 原生没有一键 clone schema 的命令，但可以用 pg_dump 只导出某个 schema 再导入到新 schema，或用 CREATE TABLE … LIKE 系列克隆表结构，实现 schema 级别的复制。去 O 场景中常用于搭建测试库、复制标准 schema 模板、批量建结构相同的分表。相比 Oracle 的 expdp/remap_schema，PG 用 pg_dump 的 –schema 选项配合导入即可实现类似效果。

PG17 对 pg_upgrade 保留订阅状态做了什么改进？

PG17 起 pg_upgrade 大版本升级可以保留逻辑复制的订阅状态（slot、subscription 等），升级后不需要重新建订阅、重新全量同步，订阅端能直接接着旧位置继续消费。这对依赖逻辑复制的生产库是重大改善，省去了升级后重建复制链路和初始同步的耗时，降低了升级复杂度和停机影响。

PG18 pg_upgrade 的 FILE_COPY strategy 是什么？

PG18 给 pg_upgrade 新增 FILE_COPY strategy（file-copy 策略），用标准文件拷贝替代默认的 hardlink 或 reflink 方式。默认 –link 用硬链接省空间但要求新旧目录同一文件系统，且风险是升级失败会污染旧数据；FILE_COPY 则真正复制文件，更安全、可跨文件系统，代价是更慢更占空间。这给用户在『速度/空间』与『安全/隔离』之间提供了更多选择。

PG18 pg_upgrade 的 swap 选项是干什么的？

swap 选项让 pg_upgrade 在完成升级后，把新旧两个数据目录互换（swap），从而减少停机窗口内的数据搬移时间，并在需要回滚时能快速切回旧版本。它改变了传统的『复制后切换』流程，让升级切换和回退更快更安全，是高可用升级场景的实用增强。

PG18 pg_upgrade 的并行框架是什么？

PG18 为 pg_upgrade 引入并行升级框架，让 catalog 重建、对象处理等可并行的阶段用多进程并行执行，大幅缩短大库的升级时间。此前 pg_upgrade 大量工作是串行的，库对象一多升级就很慢。并行框架按表/索引等对象粒度划分任务并行处理，配合 –jobs 类参数控制并行度，是 pg_upgrade 性能的一次重要飞跃。

PG18 号称的十大特性为什么被说能『干掉 Oracle 的 IMCS 内存表』？

Oracle 的 IMCS（In-Memory Column Store）是内存列式加速表，PG 社区通过列式存储引擎（如 zedstore/列存插件）+ 内存优化，提供了类似的内存/列式加速能力，配合并行、JIT、向量化执行，让 PG 也能在分析型负载上逼近 IMCS 的效果。文章调侃 PG 要『干掉 Oracle 引以为傲的 IMCS』，指 PG 生态用开源组合拳实现了内存列存加速，去 O 时不用再依赖 Oracle 的这一卖点。

PG18 把生产环境的查询计划『打包带走』是什么特性？

PG18 支持导出/导入查询计划（plan 打包），可以把生产环境里某条 SQL 的实际执行计划（连同统计信息、环境参数）打包带走，在测试环境复现并分析，用于排查执行计划回归。这让『生产计划漂移』问题可离线诊断：DBA 不用在生产反复试错，把计划带回测试环境就能定位是统计信息、参数还是数据分布导致计划变化。

PG18 统计信息迁移对 pg_upgrade 意味着什么？

PG18 支持 pg_upgrade 时导出/导入统计信息，升级后不再需要重新跑 ANALYZE，优化器立刻就能用旧统计信息生成好的执行计划。此前升级后统计信息全丢，必须全库 ANALYZE 才能恢复执行计划质量，大库 ANALYZE 很耗时。统计信息迁移打通了 pg_upgrade 的『最后一公里』，让升级后数据库立即达到生产可用状态。

PGTT 插件如何实现 Oracle 的全局临时表？

Oracle 的全局临时表（GTT）是『表结构全局共享、数据会话私有、事务级/会话级提交』，而 PG 原生临时表是『结构+数据都私有』。PGTT 插件模拟 Oracle GTT 语义：表定义持久化，数据按 session 隔离，支持 ON COMMIT PRESERVE/DELETE ROWS 两种行为。使用 PGTT 能让依赖 GTT 的 Oracle 存储过程迁移后不改逻辑，是去 O 场景常用的兼容组件。

PG_DBMS_JOB 插件为什么能降低 Oracle 迁移成本？

PG_DBMS_JOB 是 MigOps 开源的插件，兼容 Oracle 的 DBMS_JOB 定时任务接口。PG 原生有 pg_cron、pg_timetable、pg_agent 等定时方案，但函数接口与 Oracle 不一致，迁移时所有 DBMS_JOB 调用都要改写。PG_DBMS_JOB 提供与 Oracle 相同的 DBMS_JOB.SUBMIT/REMOVE/RUN 等风格接口，让 Oracle 定时任务代码几乎不改直接运行，是『为降迁移成本而生』的兼容插件。

PolarDB 开源版如何通过 orafce 支持 Oracle 兼容？

PolarDB 开源版（阿里云 PG 生态）通过 orafce 插件提供 Oracle 兼容能力，让迁移到 PolarDB 的 Oracle 应用能继续使用常用的 Oracle 函数和包。PolarDB 本身基于 PG 内核做计算存储分离等增强，叠加 orafce 后兼具云原生弹性与 Oracle 兼容，是国产云 PG 去 O 的代表方案。

PostgreSQL 如何兼容 Oracle 的 10046/10053 SQL trace？

Oracle 用 event 10046 做 SQL trace（记录等待事件、执行统计），10053 输出 CBO 优化器决策过程。PG 没有直接对应物，但可以用插件模拟：如 pg_trace 类插件、或开启 log_statement/log_min_duration_statement 记录 SQL，配合 auto_explain 输出执行计划，再结合 pg_stat_statements 统计，达到接近 10046/10053 的 SQL 诊断能力。可用插件实现 sql_trace 兼容 10046/10053，帮助 DBA 分析慢 SQL 和优化器选择。

orafce 插件提供了哪些 Oracle 兼容能力？

orafce 是 PostgreSQL 上最常用的 Oracle 兼容插件之一，提供大量 Oracle 内置函数和包的兼容实现，包括日期函数、字符串函数、nvl/nvl2/decode、regexp 系列、DBMS_* 常用包等。它让从 Oracle 迁移过来的 SQL 和存储过程能少改甚至不改直接运行，降低去 O 迁移成本。PolarDB 开源版也通过 orafce 提供 Oracle 兼容性。

orafce 新版本为什么增加 rlike 之类的函数？

orafce 不断扩充 Oracle 兼容函数，新版增加了 regexp/rlike 等正则相关函数，覆盖更多 Oracle SQL 里常用的正则表达式用法。rlike 是 Oracle/MySQL 风格的正则匹配运算符，orafce 提供对应实现让迁移 SQL 少改。这反映了 orafce 持续补齐 Oracle 函数覆盖度、降低去 O 改写量的演进方向。

pg_hint_plan 插件如何实现 Oracle 的 SQL Outline？

SQL Outline 是 Oracle 用来固定执行计划、给特定 SQL 挂 hint 的机制。pg_hint_plan 插件让 PostgreSQL 支持在 SQL 注释里写 hint（如指定索引、join 顺序、扫描方式），也能通过配置表按 SQL 指纹绑定 hint，实现类似 SQL Outline 的『不修改应用代码就干预执行计划』。这解决了 PG 没有官方 hint 的痛点，在去 O 迁移和 SQL 调优中很常用。

pg_upgrade 升级后从库为什么要重建，PG 有没有改善？

传统 pg_upgrade 只升级主库，从库因为数据文件被改动无法继续流复制，必须重建（重新做基础备份）或重搭。这在大库场景耗时很长，是 pg_upgrade 长期被吐槽的点。DB 吐槽大会专门提到『升级后从库要重建、不支持增量』。后来的 PG 版本（如 PG18 并行/统计信息迁移）优化了主库升级，但从库重建这一痛点仍主要靠基础备份工具加速，或改用逻辑复制做 minimal downtime 升级来规避。

pg_upgrade 大版本升级的基本原理是什么？

pg_upgrade 通过复用旧版本的数据文件（物理拷贝或硬链接），只重建系统 catalog 和必要元数据，把老版本的数据目录升级到新版本，避免了 pg_dump 逻辑导出再导入的漫长过程。它对数据文件做版本兼容转换，速度远快于 dump/restore，适合数据量大的升级。限制是要求新旧版本二进制兼容、插件同步升级，且需要停机（或用 –link 减少拷贝时间），升级前要跑 –check 做兼容性预检。

pgpro-pwr 插件如何实现 Oracle 的 AWR 报告？

pgpro-pwr 是 PostgreSQL 的 AWR（Automatic Workload Repository）兼容插件，定时采集实例的性能快照（等待事件、负载、SQL 统计、IO 等），生成类似 Oracle AWR 的性能报告。它帮助 PG DBA 做性能基线、负载对比和瓶颈定位，弥补 PG 官方没有内置 AWR 的空白，是去 O 后保留 Oracle 运维习惯的重要工具。

xDB Replication Server 在 Oracle 到 PG 迁移里扮演什么角色？

xDB（Replication Server）支持 Oracle、PostgreSQL、SQL Server 等异构数据库间的增量同步复制，迁移场景下常用来做『全量迁移 + 增量同步』，在切换前让目标库持续追平源库，实现近零停机切换。它通过日志解析或触发器捕获源库变更并应用到目标库，相比一次性 dump 更适合需要滚动迁移、双跑验证的场景。

大版本迁移前为什么要做业务兼容性评估？

PG 大版本间存在不兼容变更（如移除的函数、改变的行为、SQL 语法差异、扩展版本要求），迁移前不评估会导致上线后报错或行为异常。评估包括：用 pg_upgrade –check 检查二进制兼容，检查已用扩展在新版本是否有对应版本，扫描 SQL 里用的废弃特性，测试关键查询结果差异。跨版本兼容性评估工具长期缺失，需要 DBA 手动或借助工具梳理，是升级风险控制的第一道关。

异构迁移后如何做数据一致性校验？

用 count、hash 等方法做不对等迁移的一致性校验：迁移后在源库和目标库分别对每张表做行数 count，再对关键列做 hash 聚合（如 md5/聚合 hash 拼接）比对，或抽样全行 hash 比对。对超大表可以按主键分段（分片）分别 count/hash 后对比，避免单次全表聚合过慢。校验通过才能切换业务，是异构迁移（Oracle/SQL Server→PG）必不可少的收尾步骤。

用 ora_migrator + oracle_fdw 迁移 Oracle 到 PG 的流程是什么？

ora_migrator 是基于 oracle_fdw 的自动化迁移工具：oracle_fdw 让 PG 通过外部表直接访问 Oracle 数据，ora_migrator 则自动分析 Oracle 元数据、在 PG 建对应 schema/表、做类型映射和数据搬迁。流程大致是：配置 Oracle 连接 → 创建外部表 → 迁移表结构 → 拷贝数据 → 校验 → 迁移视图/序列/存储过程等对象。适合中小规模迁移，存储过程等复杂对象仍需人工改写。