姚朝明1. 从实际需求说起：为什么要在 PostgreSQL 里连 Oracle
先交代一下背景。我手上有个数据平台项目，底层主库是 PostgreSQL 16，但业务侧有一批遗留系统跑在 Oracle 12c 上。领导提的需求很直接：PostgreSQL 这边的报表应用要能实时读到 Oracle 里的订单流水，不能靠每天跑批同步，也不能在应用层做双写。说白了，就是要在 PostgreSQL 里直接查 Oracle 的表，像查本地表一样。
最初我脑子里冒出来的方案有几个：用 ETL 工具定时抽取、用消息队列做异步同步、或者干脆在 Oracle 侧开一个数据服务接口。但前两个有延迟，第三个改造成本太大，最后都被否了。于是我把目光放到了 PostgreSQL 的扩展机制上——oracle_fdw。
oracle_fdw 是 PostgreSQL 官方 wiki 收录的第三方扩展，作用就是让 PostgreSQL 能以外部表（Foreign Table）的方式访问 Oracle 数据库。这类功能在 Oracle 里叫 Database Link（DB Link），在 PostgreSQL 里对应的实现叫 Foreign Data Wrapper（FDW）。顺着这个思路，我最终实现了 PostgreSQL 跨库直连 Oracle 的目标，整个过程踩了不少坑，也把关键细节摸透了。这篇文章就把完整路线和踩坑经过写出来，给有同样需求的同行一个参考。
需要说明的是，虽然标题里带 "Public DB Links" 这个说法，但 PostgreSQL 侧并没有一个叫 "DB Link" 的内置功能，真正落地靠的是 oracle_fdw。Oracle 侧的 "Public Database Link" 概念会在后面的权限配置里用到，我后面会专门解释这个对应关系。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先厘清概念：Oracle 的 DB Link 和 PostgreSQL 的 FDW 到底怎么对应
很多人看到 "Connecting Oracle database from PostgreSQL using Public DB Links" 这个标题会犯迷糊，因为 Oracle 里确实有 "Database Link" 这个东西，而 PostgreSQL 里没有同名功能。这里先把概念彻底理清楚，否则后面的操作容易走偏。
2.1 Oracle 的 DB Link 是什么
在 Oracle 里，Database Link 是一个从当前数据库到另一个数据库的通道定义。创建一个 DB Link 之后，你可以通过 表名@链接名 的方式直接访问远端数据库里的表。DB Link 分两种：
- Public DB Link：创建时指定
PUBLIC关键字，全库所有用户都能用。 - Private DB Link：默认类型，只有创建者自己能用。
在我们的场景里，PostgreSQL 通过 oracle_fdw 连到 Oracle 时，Oracle 侧收到的连接本质上是一个普通数据库会话。如果这个会话需要访问其他 Schema 下的表，通常需要在 Oracle 侧创建对应的同义词（Synonym），或者给连接用户授予直接访问权限。如果同义词是公用的（Public Synonym），那行为上确实和 Public DB Link 很接近。
2.2 PostgreSQL 的 FDW 机制
PostgreSQL 从 9.1 版本开始引入 SQL/MED 标准，即 Foreign Data Wrapper。它的核心思路是：通过一个扩展模块，把外部数据源（可以是另一个 PostgreSQL、Oracle、MySQL、文件等）映射成本地的外部表。用户查询外部表时，FDW 负责把查询转换为对远端数据源的请求，并把结果集映射回 PostgreSQL 的行列结构。
在 PostgreSQL 里，这个链路涉及几个概念：
| 概念 | 作用 | 类比 Oracle |
|---|---|---|
| Foreign Data Wrapper | 定义访问外部数据源的驱动逻辑 | 类似 ODBC 驱动 |
| Server | 定义一个外部实例的连接信息（地址、端口、库名） | 类似 DB Link 里的连接串 |
| User Mapping | 定义本地用户到远端用户的映射关系 | 类似 DB Link 里的连接账号 |
| Foreign Table | 映射远端一张表（或视图）为本地外部表 | 类似 DB Link 里的 表@链接名 |
2.3 不同版本数据库的 FDW 差异
PostgreSQL 社区为不同数据库提供了不同的 FDW 实现，常见的有：
- postgres_fdw：官方扩展，用于连接另一套 PostgreSQL。
- oracle_fdw：社区扩展，用于连接 Oracle，由 Laurenz Albe 维护，目前是事实标准。
- mysql_fdw：社区扩展，用于连接 MySQL。
- tds_fdw：用于连接 SQL Server 和 Sybase。
既然我们的目标是 Oracle，那主角就是 oracle_fdw。
注意：oracle_fdw 不是 PostgreSQL 官方自带的扩展，安装 PostgreSQL 后需要单独编译安装。它依赖 Oracle 的客户端库（OCI），所以环境的准备比 postgres_fdw 要麻烦一些，这一步也是后面最容易翻车的地方。
3. 环境准备：oracle_fdw 的编译安装与依赖关系
oracle_fdw 的官方仓库在 GitHub，项目地址是 github.com/laurenz/oracle_fdw。安装前必须先明确一个原则：编译环境与运行环境都需要 Oracle 客户端库，而且是 64 位一致。位不一致、版本不匹配，都会在编译或连接阶段报出莫名其妙的错误。
3.1 获取 Oracle Instant Client
oracle_fdw 不是纯 C 写的驱动，它底层调用 Oracle 的 OCI（Oracle Call Interface）库。所以你需要先安装 Oracle Instant Client，它能提供最小化的 OCI 运行环境。
以 CentOS 7 为例，我当时的安装路径是 /usr/lib/oracle/21/client64，具体步骤如下：
- 到 Oracle 官网下载 Instant Client 的 RPM 包，需要下载 basic 和 sdk 两个包。basic 是运行库，sdk 是编译头文件。注意也要下载对应的 glibc 依赖包（如果系统缺的话）。
- 用 rpm 安装：
bash复制rpm -ivh oracle-instantclient21.6-basic-21.6.0.0.0-1.x86_64.rpm
rpm -ivh oracle-instantclient21.6-devel-21.6.0.0.0-1.x86_64.rpm
- 配置动态库路径：
bash复制echo "/usr/lib/oracle/21/client64/lib" > /etc/ld.so.conf.d/oracle-instant-client.conf
ldconfig
3.2 编译安装 oracle_fdw
安装前确认 PostgreSQL 的开发包已安装：
bash复制yum install -y postgresql16-devel
oracle_fdw 的安装流程比较标准，和大多数 PG 扩展一样：
bash复制git clone https://github.com/laurenz/oracle_fdw.git
cd oracle_fdw
export PATH=/usr/pgsql-16/bin:$PATH
make
make install
如果编译过程中报错找不到 oci.h，说明 ORACLE_HOME 或动态库路径没配好。可以在 make 前设置：
bash复制export ORACLE_HOME=/usr/lib/oracle/21/client64
这里需要特别提醒一个容易忽略的坑：oracle_fdw 编译时会把 OCI 库的路径写进 .so 文件。如果你编译完 Oracle Instant Client 又升级或移动了路径，oracle_fdw 会加载失败。检查方式：
bash复制ldd /usr/pgsql-16/lib/oracle_fdw.so
如果显示 libclntsh.so => not found，说明动态库路径有问题，用 ldconfig 重新配置即可。
3.3 在 PostgreSQL 侧启用扩展
编译安装完成后，在目标数据库执行：
sql复制CREATE EXTENSION oracle_fdw;
看到 CREATE EXTENSION 的返回就说明驱动本身没问题了。但如果这里报错，比如 could not load library "/usr/pgsql-16/lib/oracle_fdw.so"，那基本可以断定是 OCI 库加载失败，回到上一步排查动态库路径。
这一步的经验总结成一句话：编译安装的坑 90% 出在 OCI 库路径上，路径配好，一切顺利；配不好，各种诡异 ERROR 轮番上阵。
4. 配置流程：从 CREATE SERVER 到 FOREIGN TABLE 的完整链路
4.1 创建 Foreign Data Wrapper 和 Server
确认扩展创建成功后，第一步是创建外部服务器定义。这一步的作用是把 Oracle 的连接信息（地址、端口、服务名）告诉 PostgreSQL：
sql复制CREATE SERVER oracle_remote
FOREIGN DATA WRAPPER oracle_fdw
OPTIONS (dbserver '//192.168.10.20:1521/ORCLPDB1');
dbserver 的格式是 Oracle 的易连（Easy Connect）串：//主机:端口/服务名。这里要注意，是 Oracle 的服务名（Service Name），不是 SID。如果你的 Oracle 用的是 SID，需要写成 //192.168.10.20:1521/ORCL 这种格式，oracle_fdw 也能识别，但建议优先用服务名，因为 Oracle 12c 之后多租户架构下服务名更常用。
4.2 创建 User Mapping
PostgreSQL 本地用户要映射成 Oracle 端某个用户，通过 User Mapping 完成：
sql复制CREATE USER MAPPING FOR pg_user
SERVER oracle_remote
OPTIONS (user 'oracle_user', password 'oracle_password');
这里有几个细节值得注意：
FOR pg_user指定的是 PostgreSQL 本地用户。如果希望所有本地用户都用同一个 Oracle 账号，可以写成FOR PUBLIC。- Oracle 端的用户需要有对目标表的 SELECT 权限，如果后面要做 INSERT/UPDATE/DELETE，还需要对应写权限。
- 这个密码是以明文存在 PostgreSQL 系统表里的，安全性敏感环境下建议结合行级安全策略和数据库账号权限管控来控制访问范围。
4.3 创建 Foreign Table
映射好用户后，就可以把 Oracle 里的表映射成 PostgreSQL 的外部表：
sql复制CREATE FOREIGN TABLE ft_oracle_orders (
order_id numeric(10,0),
order_no varchar2(30),
customer_name varchar2(100),
order_date date,
amount number(12,2)
)
SERVER oracle_remote
OPTIONS (schema 'SCOTT', table 'ORDERS');
OPTIONS (schema 'SCOTT', table 'ORDERS') 里的 schema 和 table 必须用大写，因为 Oracle 的表名、列名默认是大写存储的。如果你在 Oracle 里创建表时用了双引号小写，那这里就写小写——但这种情况在 Oracle 实践中非常少见，基本可以忽略。
创建外部表时，列名也要注意大小写。PostgreSQL 侧的外部表列名如果用了小写，oracle_fdw 会自动转成大写去匹配 Oracle 列。 如果你想强制区分大小写，可以在列名前加双引号。不过一般情况下没必要，直接按小写写列名，oracle_fdw 自己会处理。
4.4 验证连接
做完上面三步，就可以验证了：
sql复制SELECT * FROM ft_oracle_orders WHERE rownum <= 10;
这里要特别小心：Oracle 里的 ROWNUM 伪列不能直接用在 PostgreSQL 侧。上面这 SQL 如果直接执行会报错，因为 PostgreSQL 不认识 rownum。正确做法是：
sql复制SELECT * FROM ft_oracle_orders LIMIT 10;
这一点和 Oracle 的习惯完全不同，刚从 Oracle 转到 PostgreSQL 的同事特别容易踩。
4.5 Oracle 侧的权限配合（与 Public DB Link 的关系）
前面说过了，oracle_fdw 连接 Oracle 时，用的是 User Mapping 里配置的账号密码。这个账号如果要访问的表不在它自己的 Schema 下，Oracle 侧需要授权。这里就涉及到标题中 Public DB Links 的相关概念了。
假设 PostgreSQL 连接的是 Oracle 的 ORA_CONN_USER 用户，它要读取 SCOTT.ORDERS 表：
sql复制-- 在 Oracle 侧执行：
GRANT SELECT ON SCOTT.ORDERS TO ORA_CONN_USER;
如果不想让后端的开发人员知道具体在哪个 Schema，也可以在 Oracle 侧创建一个公共同义词：
sql复制CREATE PUBLIC SYNONYM ORDERS FOR SCOTT.ORDERS;
这样 PostgreSQL 侧的外部表定义里，schema 就可以省略，直接写 table 'ORDERS'。这种 "公共同义词" 的思路，行为上有点像 Public DB Link 的全局可见性——只不过它只是对象名的全局解析，链接本身还是账号级别的。
所以，严格来说，oracle_fdw 的整套机制并不需要一个事先建好的 Oracle DB Link，它自己就是"链接"本身。但如果 Oracle 侧还有其他数据库实例，且你希望 oracle_fdw 连接的账号能访问那个远端实例的表，那么你就需要在 Oracle 侧先建一个 DB Link，然后给账号授这个远端表的权限，再回到 PostgreSQL 侧映射这张"远端表的同义词"。这种嵌套链路是存在的，但一般很少用到。
5. 类型映射：Oracle 与 PostgreSQL 的数据类型对应关系
跨库连接，最头疼的就是数据类型映射。Oracle 和 PostgreSQL 虽然都是关系型数据库，但类型体系差异很大。oracle_fdw 已经内置了一套默认映射规则，但实际使用时有些类型需要手动处理。
5.1 映射总表
| Oracle 类型 | PostgreSQL 类型（oracle_fdw 默认映射） | 说明 |
|---|---|---|
| VARCHAR2(n) | varchar(n) | 长度一致 |
| NVARCHAR2(n) | varchar(n) | 注意字符集差异 |
| NUMBER | numeric | 精确数值 |
| NUMBER(p,s) | numeric(p,s) | 精度自动匹配 |
| FLOAT | double precision | 浮点近似值 |
| DATE | timestamp | 注意：Oracle DATE 包含时间 |
| TIMESTAMP | timestamp | 对应无误 |
| CLOB | text | 大文本 |
| BLOB | bytea | 二进制大对象 |
| RAW(n) | bytea | 二进制 |
| ROWID | varchar(18)（只读） | 不推荐直接映射 |
| XMLTYPE | xml | 需要额外处理 |
5.2 CLOB 字段处理（热搜词里最常被问到的问题）
CLOB 映射到 PostgreSQL 的 text 类型，理论上是无损的。但在实际使用中，如果查询带上了 CLOB 字段，oracle_fdw 的默认行为会影响性能。
oracle_fdw 在读取 CLOB 时，默认会把 CLOB 转成本地文本。如果 CLOB 字段特别大，比如几 MB 甚至更大，每次查询都要传输这个字段，性能会非常差。我的经验是：查询时尽量避免 SELECT *，只在需要时显式带出 CLOB 字段：
sql复制-- 差：会把 CLOB 字段也带回来
SELECT * FROM ft_oracle_orders LIMIT 100;
-- 好：只查需要的字段
SELECT order_id, order_no, order_date FROM ft_oracle_orders LIMIT 100;
如果你确实需要 CLOB 字段，但不想在结果集里看到它，可以用 Oracle 的 DBMS_LOB.SUBSTR() 在远端截断后再传输。但 oracle_fdw 默认情况下不支持在 WHERE 条件里使用远端函数，除非你把查询下推开关打开。这个我会在性能优化章节详细说。
5.3 自增序列的映射
Oracle 的序列（Sequence）和 PostgreSQL 的序列概念类似，但语法不同。如果你在 PostgreSQL 外部表上做 INSERT，Oracle 侧的主键是由 Oracle 序列生成的，那你需要在 PostgreSQL 侧先调用 Oracle 的序列获取下一个值。
oracle_fdw 里通过 nextval() 函数来访问 Oracle 序列。比如：
sql复制SELECT * FROM nextval(oracle_remote, 'SEQ_ORDERS_ID');
这里的 oracle_remote 是前面创建的 server 名字，SEQ_ORDERS_ID 是 Oracle 侧的序列名。这个函数是 oracle_fdw 提供的，不属于 PostgreSQL 标准函数。由于 PostgreSQL 的 nextval() 对传入的 server 名和序列名有校验，使用不当会报错，建议在实际使用时直接把这个查询封装成一个 PostgreSQL 函数，避免业务侧到处裸写。
5.4 类型映射的补充经验
我在实际项目中遇到过一个问题：Oracle 的一个 NUMBER(1) 字段（通常表示布尔值），oracle_fdw 映射成 PostgreSQL 的 numeric(1,0) 后，查询没问题，但写入时如果应用层传的是 true/false，数据库会报类型错误。解决办法是在应用层做转换，或者手动创建外部表时把这个列映射成 smallint，然后在 PostgreSQL 侧再建一个视图，把 smallint 转换成 boolean。
Oracle 和 PostgreSQL 的类型对齐是跨库方案里最琐碎但又最关键的一环，建议建外部表时不要偷懒，列的类型要逐个核对，不要只靠默认映射。
6. 实战查询中的性能优化：避免全表扫描的关键设置
oracle_fdw 连上 Oracle 后，最担心的问题就是查询性能。如果每次查询都把远端整张表拉到本地再过滤，那性能会惨不忍睹。oracle_fdw 设计了一套**查询下推（Pushdown）**机制，能在一定程度上把过滤条件下推到 Oracle 端执行，减少数据传输量。
6.1 WHERE 下推
oracle_fdw 默认会尽可能把 WHERE 条件下推到 Oracle。这意味着：
sql复制SELECT * FROM ft_oracle_orders WHERE order_date >= '2024-01-01';
会被 oracle_fdw 改写成对 Oracle 的查询：
sql复制SELECT order_id, order_no, customer_name, order_date, amount FROM SCOTT.ORDERS WHERE order_date >= TIMESTAMP '2024-01-01';
但有一点要特别注意：oracle_fdw 并非所有运算符都支持下推。虽然它支持标准比较运算符（=, <, >, <=, >=, <>）和 LIKE、IN 等，但如果你在 WHERE 里用了 PostgreSQL 端自定义函数、类型转换或者某些特殊操作符，下推可能失败，这时 oracle_fdw 会把整张表拉回来在本地过滤，性能急剧下降。
怎么判断下推有没有生效？有两条路：一是查看 PostgreSQL 的日志（需要开启 auto_explain 并设置 log_min_duration），二是在 Oracle 侧开启 SQL 跟踪，看有没有收到远端实际执行的 SQL 语句。
6.2 列裁剪
oracle_fdw 会在发送查询时自动裁剪不必要的列。也就是说，如果外部表有 30 列，但你只 SELECT 了 3 列，oracle_fdw 生成的远端 SQL 也不会拉全 30 列。这在跨库查询里非常有价值，能省掉大量网络传输。
举个反例警告：如果你在查询中写了 SELECT *，oracle_fdw 会把所有列都拉回来，包括那些巨大的 CLOB、BLOB 字段。所以前面我说，始终避免 SELECT *，这不仅是代码规范问题，还直接影响跨库性能。
6.3 fetch_size 参数
oracle_fdw 创建外部表时支持 fetch_size 选项，控制每次从 Oracle 取行的数量（默认 100）：
sql复制CREATE FOREIGN TABLE ft_oracle_orders (
...
)
SERVER oracle_remote
OPTIONS (schema 'SCOTT', table 'ORDERS', fetch_size '500');
这个参数的调整要看网络环境和数据特点。如果网络延迟高、单行数据不大，适当调大 fetch_size 能显著减少往返次数。如果单行数据很大（比如包含大文本字段），fetch_size 反而要调小，避免单次传输数据量过大导致内存压力。
根据我的压测经验，局域网环境下 fetch_size 设置在 300~800 之间比较理想，超过 1000 后性能提升就不明显了，反而可能因为内存占用增加而适得其反。
6.4 remote_estimate 参数
oracle_fdw 还有一个选项叫 remote_estimate。默认情况下，PostgreSQL 对外部表的行数估算默认是 1000 行（或者你指定的值），这会导致优化器选择不合适的执行计划。开启 remote_estimate 后，oracle_fdw 会向 Oracle 发送一个 EXPLAIN 查询，获取真实的执行计划和行数估算：
sql复制CREATE SERVER oracle_remote
FOREIGN DATA WRAPPER oracle_fdw
OPTIONS (dbserver '//192.168.10.20:1521/ORCLPDB1', remote_estimate 'true');
这个选项的代价是：每次生成执行计划时都多一次 Oracle 往返。对于查询性能要求极高的场景，这个往返开销可忽略不计；但对于高频短查询场景，增加的这个 RTT 可能反而拖慢整体性能。建议在 JOIN 外部表数量多、查询复杂时开启，简单查询就不必了。
6.5 物化视图与缓存策略
即使下推做得再好，跨库查询也永远比本地查询慢。对于实时性要求不高、但频率很高的查询（比如报表页面的下拉框选项），建议在 PostgreSQL 侧建物化视图：
sql复制CREATE MATERIALIZED VIEW mv_orders AS
SELECT order_id, order_no, customer_name, order_date FROM ft_oracle_orders;
然后定期刷新：
sql复制REFRESH MATERIALIZED VIEW mv_orders;
这是用"跨库同步"的思路替代"跨库实时查询"，在报表场景里非常常见。如果刷新频率太高，可以结合 PostgreSQL 的 pg_cron 扩展或外部调度任务来管理。
我的经验总结：oracle_fdw 适合用在线查询解决"数据实时性"问题，物化视图适合解决"查询频率高"问题。两者结合，才是靠谱的跨库方案。
7. 写入操作：INSERT/UPDATE/DELETE 与事务边界
oracle_fdw 不仅支持 SELECT，也支持对 Oracle 表的写入。但写入操作有几个关键点需要在设计阶段就考虑清楚。
7.1 写入配置
如果外部表需要支持写操作，创建时不需要额外配置——oracle_fdw 会根据 PostgreSQL 的权限（外部表上的 INSERT/UPDATE/DELETE 权限）自动决定是否允许写操作。但要注意：
- 外部表的所有者（Owner） 需要被授予对应权限。
- User Mapping 对应的 Oracle 账号 需要有目标表的写权限。
- PostgreSQL 端的外部表默认插入操作不会自动填充主键，需要由应用层或 Oracle 序列提供。
7.2 事务与自动提交
oracle_fdw 的写入是声明式事务，也就是说，你在 PostgreSQL 里执行 BEGIN; INSERT ...; COMMIT; 时，oracle_fdw 会把整个 PostgreSQL 事务包装成一个 Oracle 事务。如果中途出错回滚，Oracle 端也会回滚。
但有个细节需要特别留意：oracle_fdw 默认不是两阶段提交。如果 PostgreSQL 事务涉及多张外部表（比如两个不同的 Oracle server），并且事务中执行了写操作，那么回滚时可能无法保证分布式一致性。原因在于 oracle_fdw 对每个 server 分别开启事务，PostgreSQL 崩溃时无法协调所有 Oracle 分支完成统一提交或回滚。
所以我的建议是：外部表写入操作尽量保持在单 server 内，跨 server 的强一致写入不要依赖 FDW 实现，用应用层事务或消息队列补偿更靠谱。
7.3 批量写入性能
如果你需要把大量数据从 PostgreSQL 写入 Oracle，逐行 INSERT 肯定不行。oracle_fdw 支持 PostgreSQL 的 bulk insert 机制，你可以用 INSERT INTO ... SELECT ... FROM ... 批量插入。但要注意，PostgreSQL 的 COPY 命令对 FDW 是逐行调用的，不会走批量接口，所以不要指望 COPY 能加速。
实测下来，批量插入 10 万行数据，用 INSERT INTO ... SELECT 比逐行 INSERT 快 5~10 倍。如果目标表有索引和约束，建议先禁用或延迟约束，插入完再启用，能再快一截。
7.4 UPDATE 与 DELETE 的下推
Oracle 端 UPDATE 和 DELETE 的条件也会尽量下推。但要注意，oracle_fdw 不支持 PostgreSQL 的 RETURNING 子句，所以 UPDATE ... RETURNING 会直接报错。如果你需要获取更新后的值，只能 UPDATE 之后再 SELECT 一次，这会在跨库场景下增加一次往返。
8. 常见错误排查：把 N 个真实坑位的排查链路复现一遍
我在这套方案落地过程中遇到了一堆报错，很多错误信息乍一看非常吓人，但背后原因其实很有限。下面按我实际遇到频率排序，逐个说一下。
8.1 ORA-12154: TNS:could not resolve the connect identifier specified
这个错误通常出在 dbserver 配置有误，或者 Oracle 客户端的网络配置有问题。我用的是 Easy Connect 格式，正常情况下不需要配置 tnsnames.ora。如果报这个错，优先检查：
- 地址、端口、服务名是否正确，特别是服务名的大小写。
- 是否有多余的空格或特殊字符。
- Oracle 客户端的 sqlnet.ora 是否配置了强制走 TNS 解析。
我踩过的一个坑是：Oracle 12c 之后的 CDB/PDB 架构，服务名往往和实例名不一样。如果你的服务名写成了 SID，就可能报这个错。用 lsnrctl services 在 Oracle 服务器上查看实际注册的服务名，是最靠谱的排查方式。
8.2 ORA-01017: invalid username/password; logon denied
这个错误很直白：User Mapping 里的用户名或密码不对。但有时候也会因为 Oracle 账号被锁定、密码过期导致。排查时：
- 在 Oracle 端用 sqlplus 手动验证一下账号密码。
- 查看 Oracle 的
DBA_USERS表，确认ACCOUNT_STATUS不是 LOCKED 或 EXPIRED。 - 确认 Oracle 的密码文件没有失效。
8.3 ERROR: relation "ft_oracle_orders" does not exist
这个不是连接问题，而是 PostgreSQL 侧的 SQL 写错了。比如你用大写字母创建了外部表名，查询时却用了小写。PostgreSQL 的标识符默认折叠成小写，如果你在 CREATE FOREIGN TABLE 时用了双引号且大写，那么查询时必须也加双引号且大写。
从 Oracle 转过来的同事经常在这一点上翻车，因为 Oracle 默认是大写存储表名，而 PostgreSQL 默认是小写。我的建议是：在 PostgreSQL 里坚持用小写标识符，外部表名也用小写，省掉一堆大小写麻烦。
8.4 ERROR: connection to server lost
这个问题比较隐蔽。oracle_fdw 和 Oracle 之间的连接在长时间空闲后可能被 Oracle 端的防火墙或 idle timeout 断开。如果 PostgreSQL 侧使用了连接池，连接池复用旧连接时就会报这个错。
解决思路：
- 在 Oracle 网络层面（防火墙、sqlnet.ora 的
SQLNET.EXPIRE_TIME）设置探活机制。 - 在 PostgreSQL 侧定期对外部表做探活查询（比如每分钟一条
SELECT 1），保活连接。 - 或者用 PgBouncer 之类的连接池组件，配合服务端空闲超时设置。
8.5 ERROR: Oracle error: ORA-00942: table or view does not exist
这个错误在于 Oracle 授权或 Schema 配置问题。外部表定义里的 schema 和 table 是否正确？User Mapping 对应的 Oracle 账号是否有权限访问这个表？
实践中最常见的是：Oracle 侧表是 A 用户的，但 User Mapping 连的是 B 用户，B 用户没有访问 A 用户表的权限。这种情况下，就用前面说的方式，在 Oracle 侧给 B 用户授权，或者建同义词。
8.6 断言的排查链路
如果遇到 ERROR: assertion failed 这类内部错误，多半是 oracle_fdw 版本和 PostgreSQL 版本不兼容。oracle_fdw 的版本发布节奏通常滞后于 PostgreSQL 大版本，所以升级 PostgreSQL 后忘记重新编译 oracle_fdw，就可能出现这种问题。
排查顺序：先确认 PostgreSQL 版本和 oracle_fdw 版本是否匹配，再重新编译安装，最后重新创建扩展。如果问题依然存在，到 GitHub 的 Issue 区搜一下相同报错，大概率有人踩过同一个坑。
9. 生产环境的补充建议
方案跑通之后，要在生产环境长期稳定运行，还需要考虑几个更深入的问题。
9.1 安全管控
- 尽量用独立的低权限 Oracle 账号做映射，只授业务需要的表的权限，不要用 SYSTEM 或 SYS 账号。
- User Mapping 的密码是明文存储在 PostgreSQL 的
pg_user_mappings里的，所以 PostgreSQL 侧的用户权限要控制好，避免无关人员能读到映射信息。 - 如果 Oracle 侧有审计要求，建议开启对连接账号的审计日志，方便追溯异常查询。
9.2 监控与告警
oracle_fdw 是跨库访问，任何一个环节出问题都会影响上层业务。建议在 PostgreSQL 侧建立针对外部表的监控：
- 查询外部表的慢查询日志。
- 对关键外部表做连接探活。
- 监控 PostgreSQL 到 Oracle 的网络延迟和带宽。
如果公司有 Prometheus + Grafana，可以结合 postgres_exporter 采集外部表的查询耗时指标。如果还没有这套体系，至少要在 PostgreSQL 日志里把外部表相关的执行计划打出来，方便事后排查。
9.3 备选方案对比
最后说一句公道话。oracle_fdw 是一个成熟的方案，但并不是唯一方案。我在做方案选型时也对比过其他路径：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| oracle_fdw | 实时性高、支持读写、SQL 透明 | 依赖 OCI 环境、性能受网络影响 | 实时查询、低频写入 |
| ETL 定时同步 | 稳定可控、对源库影响小 | 有延迟、需要额外维护调度 | 离线报表、数据仓库 |
| 应用层双写 + 消息队列 | 架构清晰、可扩展 | 改造成本高、需要代码开发 | 新建系统、微服务架构 |
| Oracle GoldenGate / OGG | 实时、增量、性能好 | 成本高、运维复杂 | 大规模数据迁移、容灾 |
每个方案都有自己的生存空间。oracle_fdw 的价值在于"零改造、低交付成本"，尤其适合已经有大量 PostgreSQL 投资、但还需要访问 Oracle 存量数据的团队。如果你最终选择 oracle_fdw，希望这篇文章能帮你少走点弯路，特别是编译安装和类型映射这两块，几乎每个项目都有人踩坑。