什么会导致间歇性 ORA-12519（TNS：未找到合适的处理程序）错误

Posted 2023-02-16

【中文标题】什么会导致间歇性 ORA-12519（TNS：未找到合适的处理程序）错误

【英文标题】：What can cause intermittent ORA-12519 (TNS: no appropriate handler found) errors

【发布时间】：2010-09-17 08:05:24

【问题描述】：

我们在 Oracle 10 数据库前针对 Weblogic 9 运行 Junit 4 测试套件（使用 Hudson 作为持续集成服务器），有时我们会在脚本拆卸期间遇到 ORA-12519 崩溃。但是，错误非常断断续续：

这通常发生在同一个测试类中 对于相同的测试用例并不总是会发生这种情况（有时它们会通过） 相同数量的测试用例（3-9 个）不会发生这种情况 有时根本没有发生，一切都过去了

虽然我不能保证这不会在本地发生（当然，当针对同一个数据库运行时），但我已经多次运行同一个类套件，没有任何问题。

有什么想法吗？

【参考方案1】：

不知道这是否会是每个人的答案，但经过一番挖掘，这就是我们想出的。

这个错误明明是监听器不接受连接造成的，但是为什么其他测试可以连接正常（我们也可以通过sqlplus连接没有问题）的时候会出现这个错误呢？问题的关键不是无法连接，而是间歇性

经过一些调查，我们发现在类设置过程中创建了一些静态数据，这些数据会在测试类的生命周期内保持打开的连接，并在它运行时创建新的连接。现在，即使当此类超出范围时所有资源都已正确释放（当然是通过 finally 块），但在运行期间存在某些情况下此类会吞噬所有可用连接（好吧，糟糕练习警报 - 这是直接连接而不是使用池的单元测试代码，因此在生产中不会发生同样的问题。

解决方法是不将该类设为静态并在类设置中运行，而是在每个方法的 setUp 和 tearDown 方法中使用它。

因此，如果您在自己的应用程序中遇到此错误，请在那个坏男孩身上使用分析器，看看您是否可能有连接泄漏。希望对您有所帮助。

【讨论】：

我的情况在细节上非常不同，但也归结为连接泄漏，所以感谢您为我指明正确的方向。

这里也一样。我必须在连接对象上手动添加对close() 的调用。

我的问题是关于不使用连接池。我将数据源替换为管理连接池的数据源，我的问题就解决了。 ***.com/questions/5527887/…

【参考方案2】：

我发现的另一个类似错误但相同错误消息的解决方案是增加找到的服务处理程序的数量。 （我的这个错误实例是由 Weblogic Portal 连接池中的连接过多引起的。）

运行SQL*Plus 并以SYSTEM 登录。您应该知道在安装 Oracle DB XE 期间使用的密码。 在 SQL*Plus 中运行命令alter system set processes=150 scope=spfile; 非常重要：重新启动数据库。

从这里开始：

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

【讨论】：

文章提到这是 Oracle Database XE (Express Edition) 上的一个特定问题

Oracle（完整产品）中也会出现相同的设置，但默认情况下为 150。

我看到这个问题在 jmeter 运行 40 个线程时运行。我的进程设置为 300，到目前为止最大利用率为 128。 select * from v$resource_limit where resource_name = 'processes'; = 当前=88，最大值=128，限制=300

Scope spfile 是否需要重启数据库？

Plus 50 只是在 dockerized Oracle 11.2.0.2 上解决了这个问题，是的，令人印象深刻。

【参考方案3】：

我也有同样的问题，我在很多地方搜索了答案。我得到了许多类似的答案来更改进程/服务处理程序的数量。但我想，如果我忘记重置它怎么办？

然后我尝试在每个connection.close(); 之后使用Thread.sleep() 方法。

我不知道怎么做，但至少对我有用。

如果有人想尝试一下并弄清楚它是如何工作的，那么请继续。我也想知道，因为我是编程界的初学者。

【参考方案4】：

我在单元测试中遇到了这个问题，它通过连接池打开了很多与数据库的连接，然后“停止”连接池（实际上是 ManagedDataSource）以在每次测试结束时释放连接。我总是在测试套件中的某个时候用完连接。

在我的测试的 teardown() 中添加了 Thread.sleep(500) ，这解决了问题。我认为发生的事情是连接池 stop() 释放了另一个线程中的活动连接，因此如果主线程继续运行测试，清理线程远远落后于 Oracle 服务器连接不足。添加睡眠允许后台线程释放池连接。

这在现实世界中的问题要小得多，因为数据库服务器要大得多，并且操作组合很健康（不仅仅是无休止的数据库连接/断开连接操作）。

【参考方案5】：

我有类似的问题。每次我使用SpringJUnit4ClassRunner 运行一组数据库（Spring JDBC）测试时都会发生这种情况，因此我解决了为每个测试添加@DirtiesContext 注释的问题，以便清理应用程序上下文并释放所有资源，因此每个测试都可以运行应用程序上下文的新初始化。