Oracle DB Link 明明通了，为什么一查表还是 ORA-00942？

今天处理了一个 Oracle DB Link 的小需求：从报表库访问另一套 Oracle 数据库中的业务表。

原本以为建条 Link、跑个查询就结束了，实际却接连碰到三个问题：登录本地库时报 ORA-12170，创建 DB Link 报 ORA-01031，好不容易把 Link 跑通，查业务表又报 ORA-00942。

每个报错单独看都不复杂，凑到一起就容易把排查方向带偏。尤其是最后那个 ORA-00942，我一开始也盯着权限看，后来才发现，表压根不在 DB Link 登录用户的 Schema 下面。

这次过程值得记一下。以后再碰到类似问题，不必从网络、监听、权限到对象名一起乱翻，按层拆开，几条 SQL 基本就能定位。

DB Link 排查最怕把连接、认证和对象访问混成一个问题。先证明 Link 能通，再查对象属于谁，方向会清楚很多。

先别急着创建 DB Link

这次的目标链路可以抽象成下面这样，真实 IP、账号和密码已经脱敏：

本地数据库：LOCALDB
本地用户：REPORT_USER

远端地址：10.x.x.x:1521/remote_service
远端登录用户：REMOTE_USER
目标对象：DATA_OWNER.TARGET_TABLE
DB Link：REMOTE_LINK

拿到这些信息后，第一步不是写 CREATE DATABASE LINK，而是从本地数据库服务器直接连接远端：

sqlplus REMOTE_USER@//10.x.x.x:1521/remote_service

然后根据提示输入密码。

只要这一步成功，网络、1521 端口、Listener、Service Name 和远端账号认证就有了一个基本判断。如果这里都连不上，先建 DB Link 只会把问题绕得更复杂。

第一个坑，密码里的 @ 把人带沟里了

排查远端之前，我先登录本地报表库。本地账号密码里正好包含一个 @，直接这样输入：

conn REPORT_USER/Pass@word@LOCALDB

SQL*Plus 返回了：

ORA-12170: TNS:Connect timeout occurred

看到超时，很容易先去检查网络。可这次网络没问题，真正麻烦的是连接串本身。

SQL*Plus 常见的连接格式是：

username/password@connect_identifier

密码里再放一个 @，客户端可能把它参与连接串解析。为了少跟各种 Shell 和客户端的转义规则较劲，我最后改成交互式输入：

conn REPORT_USER@LOCALDB
Enter password:

这样最省心，也不会把密码留在命令历史里。必须写在连接命令中时，需要根据客户端和终端环境正确引用，但生产环境里我更愿意直接让它提示输入。

这个坑不大，却很会误导人。明明是连接串解析问题，表面上看却像一次网络超时。

建 Link 报 ORA-01031，这次倒很直接

远端连接已经确认正常，接下来在本地用户下创建 Private DB Link：

CREATE DATABASE LINK REMOTE_LINK
  CONNECT TO REMOTE_USER
  IDENTIFIED BY "your_password"
  USING '//10.x.x.x:1521/remote_service';

结果返回：

ORA-01031: insufficient privileges

这个报错没有绕弯子。Oracle 官方文档明确要求，创建私有 DB Link 的本地用户需要 CREATE DATABASE LINK 系统权限。可以先查一下：

SELECT privilege
FROM user_sys_privs
WHERE privilege = 'CREATE DATABASE LINK';

确认业务上允许后，由具备权限的管理员授权：

GRANT CREATE DATABASE LINK TO REPORT_USER;

重新创建后，DB Link 成功落下来了。

这里还有个生产环境的小动作。如果 REPORT_USER 本来只是只读报表账号，只需要使用已经建好的 Link，并不需要以后继续创建新的 Link，可以在操作完成后评估回收建链权限：

REVOKE CREATE DATABASE LINK FROM REPORT_USER;

回收这个系统权限不会自动删除已经创建的私有 DB Link，但是否执行仍要结合账号职责和变更规范，别为了“看起来更安全”直接在生产库里顺手跑。

下次照这个顺序查

最后给自己留一份可以直接翻出来用的顺序：

1. 从本地服务器直接连接远端
   失败：检查网络、端口、Listener、Service、用户名和密码

2. 检查本地用户是否有 CREATE DATABASE LINK
   ORA-01031：核对建链权限

3. 创建 DB Link，并查询 USER_DB_LINKS 核对配置

4. 先执行 SELECT * FROM dual@dblink
   失败：继续查连接、认证和 Link 配置

5. dual 成功后，再用少量数据测试业务对象
   不要先 COUNT(*)，也不要一上来全表扫描

6. ORA-00942：查 ALL_OBJECTS / ALL_TABLES
   先确认真实 Owner，再核对对象权限和同义词

7. 使用 OWNER.OBJECT@DBLINK 重新验证

8. 按账号职责评估是否回收 CREATE DATABASE LINK

这次最费时间的地方，并不是某条 SQL 多难，而是几个名字长得太像：本地用户、远端登录用户、当前 Schema、对象 Owner，全被下意识地当成了同一个人。

以后看到 dual@dblink 已经成功，业务表却报 ORA-00942，我会先查 Owner。至少不用再陪着 Listener 和网络白忙一轮。