ora-17629 是连接建立失败的笼统报错，真实原因在于 rman 运行时环境：tnsnames.ora 加载路径错误、密码文件缺失或路径不对、inbound_connect_timeout 过短、监听器服务未注册。
ora-17629 不是网络不通的直接证据，而是连接建立失败后的笼统包装——真正原因往往藏在 rman 启动时实际使用的环境里。
检查 RMAN 连接时真正加载的 tnsnames.ora 文件位置
RMAN 并不总是读取你预期的那个 tnsnames.ora。它会按 Oracle Home 优先级顺序查找：先找 ORACLE_HOME/network/admin，但如果辅助实例由 Grid Infrastructure 管理（如 RAC 或 ASM），RMAN 很可能从 GRID_HOME/network/admin 加载配置——而这个目录下常为空或缺失对应别名。
常见错误现象：tnsping pri 成功、sqlplus /@pri 成功，但 RMAN duplicate 失败。
- 用
ps -ef | grep rman查看 RMAN 进程启动时的ORACLE_HOME和GRID_HOME - 确认该 HOME 下的
$ORACLE_HOME/network/admin/tnsnames.ora是否包含目标数据库的完整条目（注意大小写、括号嵌套和换行） - 临时验证：把
tnsnames.ora复制到GRID_HOME/network/admin/，再重试
验证密码文件是否被正确识别（尤其 Windows 或非标准路径）
ORA-17627 + ORA-01017 组合报错，90% 以上不是密码输错，而是 RMAN 根本没找到可用的密码文件。
Windows 下默认路径是 %ORACLE_HOME%\database\，Linux 是 $ORACLE_HOME/dbs/；如果手动复制了密码文件但放错位置，RMAN 就会静默跳过认证，最终触发 ORA-17629。
- 检查目标库和辅助库各自的密码文件路径是否符合平台规范
- 运行
orapwd file=<path> password=<pwd> force=y format=12</pwd></path>重建密码文件（避免旧格式兼容问题） - 确认
remote_login_passwordfile参数为EXCLUSIVE，且主备库 SID 完全一致（大小写敏感）
排查 INBOUND_CONNECT_TIMEOUT 导致的“假超时”
Oracle 10.2+ 默认 INBOUND_CONNECT_TIMEOUT 为 60 秒。若网络延迟高、DNS 解析慢或监听器负载重，RMAN 在完成身份验证前就被强制断开，日志只显示 ORA-17629，不提示超时。
这个参数在 sqlnet.ora 中设置，影响所有客户端连接，但 RMAN 的后台通道（如用于传输控制文件的 auxiliary 连接）对此尤其敏感。
- 在目标库和辅助库的
$ORACLE_HOME/network/admin/sqlnet.ora中添加：INBOUND_CONNECT_TIMEOUT = 180 - 重启监听器：
lsnrctl reload - 避免设为 0（禁用超时），这会带来安全风险
不要忽略辅助端监听器注册状态
RMAN duplicate 过程中，辅助实例需要多次启停；每次启动后，监听器必须能动态注册服务名（如 orcl_stb）。如果监听器未启用、静态注册遗漏、或 local_listener 配置错误，RMAN 就会在尝试连接辅助实例时卡住并报 ORA-17629。
- 登录辅助库执行：
lsnrctl status，确认目标服务名出现在 “Services Summary” 中 - 检查
listener.ora是否有GLOBAL_DBNAME匹配你的 TNS 别名中的SERVICE_NAME - 临时改用静态注册测试（在
listener.ora中显式定义 SID_LIST），排除动态注册延迟问题
最易被忽略的一点：RMAN duplicate 命令里写的 @pri，和它背后真正去哪读 tnsnames.ora、用哪个 ORACLE_HOME 启动、连哪个监听器、是否能拿到密码文件——这四个环节只要一个脱节，就只会统一抛出 ORA-17629。别只盯着网络连通性，先定位 RMAN 当前运行上下文。
