概述

今天邮件收到了很多Oracle数据库告警，看了下alert log，很多类似的Process P607 submission failed with error报错，截图如下：

下面简单记录下解决过程，仅供参考。

解决过程

1、查询视图

查询这个视图主要看看process和session是否达到最大限制，通常情况下都是process达到最大限制导致的。

SQL> set line 1000SQL> set pagesize 1000SQL> col RESOURCE_NAME for a50SQL> col INITIAL_ALLOCATION for a30SQL> col LIMIT_VALUE for a60SQL> select * from v$resource_limit;

说明：CURRENT_UTILIZATION：表示当前大小MAX_UTILIZATION ：系统曾经达到最大数INITIAL_ALLOCATION ：参数设置大小

此时可以使用alter system set process=XX scope=spfile语句增加最大限制，然后重启数据库。但是有时是因为过多的连接未释放造成的process达到上限。

SQL> select count(*) from v$session where status='INACTIVE';

2、数据库建议process

alter system set processes=1200 scope=spfile; alter system set sessions=1325 scope=spfile; 

目前阈值为800，process曾达到最大值为800，建议适当调整为1200

参考：session与process的设置关系session：指定了一个实例中允许的会话数，即能同时登录到数据库的并发用户数。process: 指定了一个实例在操作系统级别能同时运行的进程数，包括后台进程与服务器进程。一个后台进程可能同时对应对个会话，因此通常sessions的值是大于processes的值

通常的设置公式

sessions = 1.1 * processes + 5

ps:关于INACTIVE状态的session

session的active状态官方解释如下：

Any session that is connected to the database and is waiting for an event that does not belong to the Idle wait class is considered as an active session.

session的inactive状态是指语句已经执行完成，处于等待状态的session。通常是应用程序中没有释放的连接引起的。

具体情况具体分析，这个报错还是比较明显的，当然如果平时是正常的，我们更应该思考为什么会突然增加这么多进程，是因为sql问题多了很多无效连接导致还是其他层面，这个就得根据实际业务判断了。后面会分享更多DBA方面的内容，感兴趣的朋友可以关注一下~