ORACLE 12.2 RAC TNS-12520 遭遇连接风爆 (connection storm)

故障现象：数据库迁移到新环境刚过两天。今天生产核心数，断断继续的告警连接不上。这是问题！

如理思路：1.查看alert日志，日志无报错

2.查看连接数，参数设置的2000，历史最高连接1706，当前连接1698 ，初步一看，排除了连接数不够的问题。

3.查看监听日志，第一次查询，由于断断续续断不上，并没有仔细看查。并未发现问题。在第二次查看时，发现监听日志中有出现 TNS-12520 错误，并有 service_update * servicename * 0 信息

查询资料：

1. 网上查询是ORA-12520 ,大多数是说tnsname.ora 中(server=shared) 改成(server=dedicated) 由于程度未并改配置，又是断断续续，加上网上是ORA-12520(alert中并未有这个错误 )，可以排除这个问题。为了稳妥起见，我通过监听日志，找到连接失败的IP，登录到业务服务器确认， tnsname.ora 的配置就是dedicated

2.process不够引起的，可以排除这个问题，当前参数限制是2000，而我历史最高连接也就1706个。

3.通守MOS 查询TNS-12520 .找到文档 ID 2321889.1 其现象和现场一致。

文档中参数是设的3000，历史最高连接3000，当前连接2723

其主要内容是说，pmon将定期注册到侦听器，并将DB当前进程号发送给侦听器。当前连接数已是2723 个连接，在没有释放连接数的情况下，侦听器将只允许300个新连接（3000 - 2700），直到下一次pmon注册发生。

在大多数情况下，这可能就足够了，因为PMON或LREG将在短时间内注册到监听器，而现在应用程序很可能使用连接池。

但是，如果发生登录风暴或连接数量的显着峰值，则可能发生TNS-12520错误，然后在实例更新侦听器进程所花费的时间内清除。

这是错误转瞬即自纠的情况(即出现后马上恢复)。

例：08-OCT-2017 19:55:01 * service_update * servicename * 0

解决办法：

核实数据库有较多短连接，跟业务说清楚，1.把短连接改为长连接 2.降低总体连接数 3.增大数据库连接数processes参数

APPLIES TO:Oracle Net Services - Version 11.2.0.4 to 12.2.0.1 [Release 11.2 to 12.2]

Information in this document applies to any platform.

SYMPTOMS

DB init parameter processes is set to 3000, TNS-12520 is seen in listener.log intermittently even v$resource_limit only shows a max value 2723 for process MAX_UTILIZATION:

RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE CON_ID
processes 1025 2723 3000 3000 0
sessions 935 2199 4536 4536 0

CAUSE

This is an expected behavior when login storm occurred with below justification:

pmon will register to listener periodically, and it sends the DB current process number to the listener. In this case, max allowed processes is 3000, and current processes is 2700, so that the listener will only allow 300 new connections (3000 - 2700) until another pmon registration happened.

It could be sufficient in most cases, since the PMON or LREG will register to the listener in a short time, and nowadays applications are most likely using connection pool.

But if a login storm or significant spike in the number of connections occurs, the TNS-12520 error can occur then clear in the time it takes for the instance to update the listener process.

This is a case where the error is fleeting then self corrects.

eg: Below is example of service registration

08-OCT-2017 19:55:01 * service_update * servicename * 0

SOLUTION

Identify the client or application server where these connections originate and tune that client so that the number of connections can be managed by your database.

来源： https://support.oracle.com/epmos/faces/SearchDocDisplay?_afrLoop=289633009408917&_afrWindowMode=0&_adf.ctrl-state=hty6dmkdp_4

来自为知笔记(Wiz)