今天处理了一个 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 和网络白忙一轮。
