oracle JDBC 连接失败，ORA-12516
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10281523/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JDBC connection failing with ORA-12516
提问by TimK
I have some unit tests that talk to Oracle-11g XE. Running each test individually works fine, but when I run them all, the first few pass, and the rest fail with this error when trying to create the DB connection:
我有一些与 Oracle-11g XE 对话的单元测试。单独运行每个测试工作正常，但是当我运行它们时，前几个通过，其余的在尝试创建数据库连接时失败并出现此错误：
ORA-12516, TNS:listener could not find available handler with matching protocol stack
This happens no matter what order I run the tests in, so the problem seems to be that I'm using up some kind of resource on the DB server.
无论我运行测试的顺序如何，都会发生这种情况，所以问题似乎是我用完了数据库服务器上的某种资源。
I tried running the tests slowly, and checking the # of connections in use during the run with:
我尝试缓慢运行测试，并检查运行期间使用的连接数：
select count(*) from v$session;
The # of sessions always hovers between 26 and 28, and the limit is set to 49, so I'm not sure what the problem is.
会话数总是在 26 到 28 之间徘徊，并且限制设置为 49，所以我不确定问题是什么。
The problem also gets worse if I run the tests quickly. When I run them without any added delays, 90% fail with this error. I put a sleep in tearDown() to get a better idea of what's going on, and in that case only about 10% fail.
如果我快速运行测试，问题也会变得更糟。当我在没有任何额外延迟的情况下运行它们时，90% 会因此错误而失败。我在 tearDown() 中休眠以更好地了解发生了什么，在这种情况下，只有大约 10% 失败。
回答by Glenn
You probably need to increase the value of the PROCESSES parameter. Also do a "lsnrctl servcies" command to see if the service is showing up as blocked. I recall a similar issue where the listener is being smart and counting the number of connections being requested for the service. The listener doesn't learn about the disconnects until PMON notifies it. And that can be 5 or 10 minutes later. So the listener thinks you have a lot of open connections and decides to be proactive and not hand out anymore connections -until it is told otherwise by PMON. If you increase the PROCESSES parameter, you might be able to bump yourself up to the number of connections you might make in the window.
您可能需要增加 PROCESSES 参数的值。还可以执行“lsnrctl servcies”命令以查看服务是否显示为已阻止。我记得有一个类似的问题，其中侦听器很聪明并计算服务请求的连接数。侦听器在 PMON 通知它之前不会了解断开连接。这可能是 5 或 10 分钟后。因此，侦听器认为您有很多打开的连接，并决定积极主动，不再分发连接 - 直到 PMON 另有通知。如果您增加 PROCESSES 参数，您可能会增加您可能在窗口中建立的连接数。
UPDATE: This link describes it: https://forums.oracle.com/forums/thread.jspa?threadID=360226
更新：此链接对其进行了描述：https: //forums.oracle.com/forums/thread.jspa?threadID=360226
回答by Filip
A few years later...
几年后...
see : http://www.eddgrant.com/blog/2010/01/20/increasing-the-number-of-processes-in-oracle-xe.html
见：http: //www.eddgrant.com/blog/2010/01/20/increasing-the-number-of-processes-in-oracle-xe.html
running this in Sql Plus solved my problem :
在 Sql Plus 中运行它解决了我的问题：
SQL> alter system set sessions=300 scope=spfile;
SQL> alter system set processes=300 scope=spfile;
回答by Denis.Kuznetsov
Look at the sessions and process limits in v$parameters and also alert.log and listener.log The answer is somewhere out there
查看 v$parameters 中的会话和进程限制以及 alert.log 和 listener.log 答案就在那里
