ORA-28536报错，异构服务初始化参数出问题了，远程处理卡住怎么破

ORA-28536这个错误，说白了就是Oracle数据库想去找一个不是Oracle的“外人”数据库（比如SQL Server、MySQL、DB2这些）聊天，但是负责牵线搭桥的那个中间人——“异构服务”没准备好，或者传话的指令（初始化参数）写错了，导致话还没说出口就卡住了，整个过程就像是你想让你家小狗（Oracle数据库）去隔壁家拿个东西，但你给它的指令含糊不清，或者它根本不认识去隔壁家的路，小狗就在门口转圈,然后失败地回来了。

根据Oracle官方支持文档（Oracle Support Doc ID 452959.1, 207303.1等）以及大量DBA的实践经验，这个问题几乎百分之百可以确定是出在Oracle的监听器配置文件listener.ora和数据库初始化参数文件（如spfile或pfile）中，那个专门用于定义如何连接非Oracle数据库的HS（Heterogeneous Services）配置部分，下面我们就来一步步排查，看看到底是哪个环节“掉链子”了。

第一步：检查最明显的嫌疑犯——监听器配置（listener.ora）

这个文件就像是Oracle数据库的“总机接线员”的工作手册，它告诉监听器：“当有请求要找某个特定的服务名时，你应该把它转接到哪个具体的程序去处理。” 对于异构连接，这个“具体的程序”就是异构服务代理进程。

最常见的错误出在SID_DESC这个部分的参数设置上，你需要打开你数据库服务器上的$ORACLE_HOME/network/admin/listener.ora文件，找到针对你的异构服务配置的那一段,关键要检查以下几点：

1. SID_NAME是否写对了？ 这个SID_NAME必须和你后面在数据库参数中指定的HS_SID_NAME完全一致，大小写？在大多数情况下，Oracle是区分大小写的，所以必须一模一样，比如你一边写的是“MYSQLDB”，另一边写的是“mysqldb”,那肯定对不上。
2. ORACLE_HOME路径对不对？ 这个路径必须指向你当前正在使用的这个Oracle数据库的家目录，如果你有多个Oracle版本装在同一台机器上,很容易搞混。
3. PROGRAM的名字对不对？ 这是最关键的一项，它指定了具体由哪个可执行文件来负责和远程数据库对话，连接SQL Server通常用的是dg4odbc，连接Sybase用的是dg4sybs，你必须根据你要连接的目标数据库类型，填写正确的程序名,你不能让一个只会说英语的翻译去翻译日语。

第二步：检查数据库端的“接头暗号”——初始化参数

光“总机接线员”知道怎么转接还不行，发起请求的数据库实例自己也得知道对接的“暗号”，这些暗号是通过在Oracle数据库实例中设置一些特定的初始化参数来定义的，你需要用DBA账号登录数据库,检查以下参数：

1. HS_FDS_CONNECT_INFO： 这是最重要的参数之一，它告诉了异构服务代理：“你实际上去连接那个远程数据库时，用的连接串是什么。” 这个串的格式完全取决于你用的那种代理程序，如果你用dg4odbc连SQL Server，这里的值可能是一个ODBC数据源名称（DSN），你必须确保这个参数的值是有效的,并且能被代理程序正确理解。
2. HS_FDS_TRACE_LEVEL： 这个参数用于开启跟踪，当问题很难排查时，把这个参数的值设成OFF以外的级别（比如DEBUG），会让异构服务代理产生非常详细的日志文件，这就像是给整个对话过程装了窃听器，虽然日志会很大，但里面往往藏着出错的根本原因，查看$ORACLE_HOME/hs/log目录下的日志文件是解决问题的杀手锏。
3. HS_FDS_RECOVERY_ACCOUNT 和 HS_FDS_RECOVERY_PASSWORD： 如果涉及到分布式事务（比如跨数据库的转账），这两个参数用于指定一个用于故障恢复的账户，虽然不总是导致28536错误的直接原因，但如果配置不当,可能会在后续步骤出问题。

第三步：别忘了ODBC这个“二传手”

如果你的异构连接是通过ODBC驱动的（比如连接SQL Server、MySQL等非常常见），那么ODBC本身的配置也是一个“重灾区”，你需要在Oracle数据库服务器上,配置一个系统DSN或者用户DSN。

• 数据源（DSN）名称匹配吗？ 确保你在HS_FDS_CONNECT_INFO参数里写的DSN名称,和在ODBC数据源管理器里创建的那个DSN名称分毫不差。
• ODBC驱动本身没问题吗？ 有时候ODBC驱动版本太老、不兼容，或者干脆损坏了，也会导致连接卡住，可以尝试用系统自带的odbcad32.exe工具测试一下这个DSN能否正常连接上目标数据库，如果ODBC这一层自己都连不上,那Oracle这边再怎么配置也是白搭。

第四步：重启服务，让配置生效

这是一个非常关键但容易被忽略的步骤，你对listener.ora文件的任何修改，都必须重启监听器服务才能生效，仅仅在数据库里改几个参数后重启数据库实例是不够的,正确的顺序是：

1. 修改listener.ora和数据库初始化参数。
2. 停止Oracle监听器服务：lsnrctl stop。
3. 重启Oracle监听器服务：lsnrctl start。
4. 如果修改了数据库参数，可能需要重启数据库实例（如果参数不是动态参数的话）。

总结一下破局思路：

当遇到ORA-28536时，不要慌，它几乎总是一个配置错误，而不是什么高深莫测的bug，你就按照上面的路径,像一个侦探一样逐一排查：

• 先核对“名单”：检查listener.ora里的SID_NAME和数据库参数里的HS_SID_NAME是否一致。
• 再确认“翻译官”：检查listener.ora里的PROGRAM是否指定了正确的异构服务代理程序。
• 然后检查“接头指令”：检查数据库参数HS_FDS_CONNECT_INFO是否提供了有效的、格式正确的连接信息。
• 最后验证“通信线路”：如果用了ODBC,确保ODBC数据源配置正确且可独立连接。

如果所有这些都检查过了还是不行，那就祭出终极武器：开启HS跟踪（HS_FDS_TRACE_LEVEL），重现一下错误，然后去仔细阅读生成的跟踪日志文件，日志里通常会明确指出的错误信息，无法加载某个DLL”、“用户名密码错误”、“找不到指定的数据源”等,这会让你直接找到问题的根源。