dblink跨库查询需显式指定link_name、connect to...identified by...、using 'connect_string'三部分，缺一报ora-00922；ora-02019主因连接描述不可达，须检查tnsnames.ora、连接串语法及tnsping连通性。
Oracle 中跨库查询数据，DBLINK 是最直接、最轻量的方案——但它不是“建了就能用”，权限、连接串、全局名、网络通路这四关卡住 80% 的人。
CREATE DATABASE LINK 语句里哪些参数不能省？
必须显式指定的只有三部分：link_name、CONNECT TO ... IDENTIFIED BY ...、USING 'connect_string'。漏掉任意一个都会报 ORA-00922: missing or invalid option。
-
link_name可以任意命名（除非GLOBAL_NAMES=TRUE，此时必须和远程库的global_name完全一致） -
CONNECT TO后的用户名密码，是远程库的登录凭证，不是本地库的；如果省略，Oracle 会尝试用当前会话用户去连远程库，大概率失败 -
USING后的连接串，可以是tnsnames.ora中已定义的别名（如'ORCL_REMOTE'），也可以是完整描述（如'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))'）
为什么 SELECT * FROM table@dblink 总是报 ORA-02019？
这个错误本质是“找不到远程数据库的连接描述”，不是账号错、也不是表不存在。优先排查以下三点：
- 本地数据库服务器上，
$ORACLE_HOME/network/admin/tnsnames.ora文件是否真实存在且可读（注意：是本地 DB server 的文件系统，不是你本地电脑） - 如果用了
USING 'xxx'直接写连接串，检查括号是否配对、等号前后有没有多余空格、SERVICE_NAME或SID是否拼写正确（大小写敏感） - 用
tnsping xxx在本地数据库服务器命令行测试连接串是否可达（不是在 SQL*Plus 里跑）
PUBLIC 和私有 dblink 的权限行为差异
创建时加不加 PUBLIC 关键字，决定了谁有权使用它：
- 不加
PUBLIC（即CREATE DATABASE LINK mylink ...）：只有创建者本人能用@mylink，其他用户执行SELECT * FROM t@mylink会报ORA-00942: table or view does not exist - 加
PUBLIC（即CREATE PUBLIC DATABASE LINK mylink ...）：所有用户都能用，但前提是创建者必须有CREATE PUBLIC DATABASE LINK权限（普通CREATE DATABASE LINK权限不够） - 无法“授权”私有 dblink 给别人——这是 Oracle 的硬限制，想让别人用，只能重建为
PUBLIC，或换账号创建
dblink 查询慢或超时，该查什么？
这不是 SQL 写得不好，而是跨库链路本身的问题：
- 远程表没建索引，或者
WHERE条件无法下推到远端（比如用了本地函数包裹列：UPPER(name)@dblink = 'ABC'），会导致整表拉回本地过滤 - 网络延迟高，特别是跨机房或走公网时，
SQL*Net message from client等待时间会暴涨 - 远程库负载高或锁表，你的查询会在
enq: TX - row lock contention或SQL*Net more data from dblink上长时间挂起 - 建议加
/*+ DRIVING_SITE(t) */提示强制驱动端在远程库执行（t是远程表别名），避免本地做 join 或排序
真正容易被忽略的是：dblink 的生命周期完全依赖网络和远程库可用性，它不像视图或同义词那样“静态”。一次网络抖动、远程库重启、防火墙策略变更，都可能让前一天还跑得好好的查询突然报错，而且错误码分散（ORA-02068、ORA-12154、ORA-03113…），得结合 tnsping 和远程库的 listener.log 一起看。
