ORA-15507错误导致实例无法启动工作负载回放，远程指导修复方案分享

ORA-15507错误导致实例无法启动工作负载回放，远程指导修复方案分享 来源：根据一次真实的Oracle数据库技术支持案例记录整理）

那天下午，我们团队接到一个紧急求助电话，客户DBA的声音非常焦急，他说他们的一个关键测试数据库在尝试启动工作负载回放（Workload Replay）时，突然失败了，数据库实例抛出了一个ORA-15507错误，导致整个压力测试流程卡住，无法继续进行，由于测试计划非常紧张，他们急需远程支持来快速定位并解决问题,我们立即通过远程桌面连接到了客户的服务器。

我们让客户复现一下操作和错误，客户在SQL*Plus中执行了启动工作负载回放的命令： BEGIN DBMS_WORKLOAD_REPLAY.START_REPLAY (replay_name => 'TEST_REPLAY_01'); END; / 执行后，数据库确实返回了明确的错误信息：ORA-15507: 无法启动工作负载回放 TEST_REPLAY_01，这个错误信息本身比较笼统,没有直接指出根本原因。

（来源：现场复现的错误信息截图）

我们的第一步是查看更详细的日志信息，我们指导客户检查数据库的告警日志文件（alert_SID.log），在告警日志中，我们找到了与ORA-15507相关的一条更具体的记录，日志中写着：“WARNING: Replay client processes did not connect within the timeout period.” 这给了我们一个非常关键的线索：问题出在重放客户端（Replay Clients）与重放调度器（Replay Coordinator）的连接上，就是发令枪响了（START_REPLAY命令），但运动员（Replay Client进程）没有在规定时间内跑到起跑线。

（来源：数据库告警日志文件内容）

我们需要弄清楚为什么重放客户端没有连接上,原因可能出在以下几个方面：

1. 重放客户端进程（wrc）根本没有被启动。
2. 重放客户端启动时指定的连接信息（如TNS连接字符串）不正确。
3. 网络问题,例如防火墙阻塞了连接端口。
4. 重放调度器所在的数据库实例负载过高,无法及时响应客户端的连接请求。

我们首先排除了第4点，因为这是一个专用的测试环境，当时实例的CPU和内存使用率都非常低，我们让客户检查他们是否启动了重放客户端，客户非常肯定地说，他们已经在一个独立的命令行窗口中使用了类似 wrc mode=replay replaydir=/u01/replay 的命令启动了多个wrc进程。

既然客户端已经启动，我们开始怀疑是连接信息的问题，我们让客户检查一下wrc命令中是否明确指定了连接字符串，客户反馈说，他们的命令里没有加connect参数，是依赖默认的TNS连接,这很可能就是问题的根源。

我们解释说，重放客户端（wrc）需要知道如何连接到正在进行重放的数据库实例，如果不在命令中通过connect参数明确指定，它会尝试使用环境变量（如TWO_TASK）或本地的tnsnames.ora文件中的默认服务名进行连接，如果这些配置不正确,客户端就无法找到数据库。

为了验证这一点,我们让客户执行了两个检查：

1. 在启动wrc的同一用户环境下，使用tnsping命令测试一下是否能正确解析到目标数据库的服务名，客户执行了 tnsping PROD_TEST （假设服务名为PROD_TEST），结果返回“TNS-12541: TNS:无监听器”,这是一个重大发现！
2. 我们让客户立刻检查数据库的监听器状态，lsnrctl status，发现监听器确实是启动的，但里面注册的服务名并不是PROD_TEST，而是PROD_TST。

（来源：客户的tnsping命令返回结果和lsnrctl status命令输出）

问题水落石出了！客户在启动wrc时，系统试图连接一个名为PROD_TEST的服务，但数据库监听器里实际存在的服务名是PROD_TST，少了一个字母“E”，这导致重放客户端一直无法建立连接，最终触发了超时，报出ORA-15507错误。

找到了根本原因，修复方案就非常简单直接了，我们给了客户两个解决方案,任选其一：

修改wrc启动命令，直接指定正确的连接字符串。 我们让客户停止之前所有启动的wrc进程，然后使用新的命令重新启动，新命令如下： wrc mode=replay replaydir=/u01/replay connect=username/password@PROD_TST 这样，客户端就会明确地连接到PROD_TST服务,绕过了错误的TNS配置。

修正本地的TNS网络服务名配置。 我们指导客户编辑$ORACLE_HOME/network/admin/tnsnames.ora文件，将里面指向错误服务名的配置项改正，或者创建一个新的、正确的配置，将PROD_TEST对应的SERVICE_NAME值改为PROD_TST,或者确保环境变量TWO_TASK指向一个正确的服务名配置。

客户选择了更彻底的方案二，他们修正了tnsnames.ora文件，修改完成后，他们再次使用tnsping PROD_TEST，这次成功解析并连接，随后，他们重新启动了wrc进程，这一次，当我们再次在SQL*Plus中执行DBMS_WORKLOAD_REPLAY.START_REPLAY命令时，命令被顺利执行，告警日志中也出现了重放客户端成功连接并开始处理负载的记录，ORA-15507错误被成功解决。

（来源：修复后成功的START_REPLAY命令执行结果和告警日志记录）

回顾这次远程排障过程，核心思路可以总结为：当遇到笼统的错误代码时，第一时间查看详细日志；根据日志提示，将大问题分解为几个具体的、可验证的小环节；然后像侦探一样，逐一排查每个环节，从最可能出错的点（比如网络连接、配置参数）入手。 对于ORA-15507，告警日志中的“Replay client processes did not connect”是指引我们走向解决方案的明灯，而基础的网络连通性检查（tnsping）则是锁定故障点的关键工具，这次经历也提醒我们，在分布式任务中,任何一个环节的微小配置不一致都可能导致整个任务失败。