ORA-01017在DBLink场景下根本原因不是本地密码输错，而是远程库账号被删/锁/过期、大小写不匹配、缺少CREATE SESSION权限，或DBLink凭据未随远程密码变更而更新。
ORA-01017 出现在 DBLink 场景时，根本不是密码输错了
DBLink 创建时指定的 CONNECT TO username IDENTIFIED BY password，会在远程库做一次独立认证。此时报 ORA-01017，90% 的情况和本地登录无关——远程库里的那个 username 账号可能已被删、被锁、密码已过期，或者大小写不匹配（Oracle 11g+ 默认口令区分大小写）。更隐蔽的是：该用户可能没被授予 CREATE SESSION 权限，导致认证通过后立刻被拒，仍报 ORA-01017。
验证方法很简单：
- 在本地服务器上，用完全相同的账号密码直连远程库：sqlplus username/password@remote_tns
- 如果也报 ORA-01017，问题 100% 在远程端；如果能连上，再查 DBLink 定义里的 host 或 service_name 是否指向了别的 PDB/实例（比如误连测试库）
public DBLink 的权限校验走的是 SYS.user$，不是当前用户
创建 CREATE PUBLIC DATABASE LINK 时，Oracle 把连接凭据存进 SYS.user$ 表，而非调用者的 schema。这意味着：
- 即使你用 SCOTT 用户创建了 public dblink，实际认证身份是远程库中那个 username 对应的账户
- SCOTT 本身不需要任何特殊权限，但必须有 CREATE PUBLIC DATABASE LINK 系统权限（由 SYS 授予）
- 远程库的 username 必须具备 CREATE SESSION，且不能被 ALTER USER ... ACCOUNT LOCK 锁定
- 若远程库启用了密码复杂度策略，而 DBLink 中的密码不符合新策略（如长度不足），也会静默失败
ORA-03150 往往是 ORA-01017 的“马甲”
当 DBLink 认证成功、但后续初始化会话失败（例如远程用户没有 SELECT 权限访问目标表，或触发器执行报错），Oracle 可能不返回具体错误，而是直接断开连接，抛出 ORA-03150: end-of-file on communication channel。这时要结合 ORA-02063（它会紧跟着出现，提示“preceding line from dblink_name”）来定位源头。
排查建议：
- 在远程库开启 SQL trace：ALTER SYSTEM SET EVENTS '10046 trace name context forever, level 12';
- 然后从本地发起一次 SELECT * FROM dual@your_dblink;
- 查看远程库生成的 trace 文件，确认失败点是否在权限检查阶段
- 特别注意：如果远程库是 Oracle 12c+ 且使用了统一审计（Unified Audit），某些权限拒绝不会写入 alert log，只出现在 audit log 中
DBLink 密码明文存储在数据字典里，但 12c+ 可能被加密
Oracle 12.2 开始，dba_db_links.password 列默认显示为 ****，真实密码只保留在创建时的 DDL 语句或配置管理工具中。这意味着：
- 无法从目标库直接查出 DBLink 使用的明文密码
- 如果原库已不可达，又没备份建链脚本，只能重置远程账号密码并重建 DBLink
- CREATE DATABASE LINK ... CONNECT TO CURRENT_USER 可规避密码存储问题，但它要求远程库已配置好 proxy user 映射（ALTER USER remote_user GRANT CONNECT THROUGH local_user），且本地用户必须有 CONNECT THROUGH 权限
真正容易被忽略的是：DBLink 创建后，远程账号密码一旦变更，DBLink 不会自动同步——它永远只认创建那一刻的凭据。运维中常有人改了远程密码却忘了刷新所有依赖该账号的 DBLink。
