很多情况下，我们是不推荐修改Oracle默认的参数（特别是一些隐含参数）。Oracle的默认值参数可以适应大部分情况，但是一些时候还是要注意进行适当的修改，来适应实际开发的需要。

今天进行数据库例行检查，发现在alert_log中出现报错信息。

--Alert Log相关部分

Tue May 03 14:44:25 2011

ORA-00020: maximum number of processes 150 exceeded

ORA-20 errors will not be written to the alert log for

 the next minute. Please look at trace files to see all

 the ORA-20 errors.

Tue May 03 14:45:24 2011

Process J001 submission failed with error = 20

kkjcre1p: unable to spawn jobq slave process

Errors in file /nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_cjq0_12320848.trc:

这个代码片段报错两个。首先在下午2点44分25秒的时候，报错ORA-00020，提示说当前的process数量超过了约定的150个。其次是在一分钟之后，报错说后台进程J001不能连接数据库，别数据库实例剔除。

检查对应生成的trace文件，可以看到。

--Trace File内容

Trace file /nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_cjq0_12320848.trc

（篇幅原因，有省略…）

*** 2011-05-03 14:45:24.033

ORA-00020: No more process state objects available

Setting Resource Manager plan SCHEDULER[0x3004]:DEFAULT_MAINTENANCE_PLAN via scheduler window

*** 2011-05-03 22:00:00.057

Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter

在trace文件的反映情况上，在开始一个资源管理作业的时候，启动的J001进程。在这个过程中，因为不能创建新的进程，所以报错。

从时间和关联上，可以认定两个错误是一个原因。最开始报错的Ora-20错误是原因，而之后的J001进程被剔除是结果。

检查20错误的信息。

[oracle@oracle11g ~]$ oerr ora 00020

00020, 00000, "maximum number of processes (%s) exceeded"

// *Cause:  All process state objects are in use.

// *Action: Increase the value of the PROCESSES initialization parameter.

错误提示告诉我们，当系统中进程的数量超过了设置参数Processes的值时，就会出现20错误，同时将超出限额的进程踢出系统。于是乎J001作业进程就被剔除了进程，形成了之后的报错。

当前系统中processes的取值是多少呢？

SQL> show parameter processes;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

aq_tm_processes                      integer     0

db_writer_processes                  integer     1

gcs_server_processes                 integer     0

global_txn_processes                 integer     1

job_queue_processes                  integer     1000

log_archive_max_processes            integer     4

processes                            integer     150

此时采用的是默认值150。这样问题就清楚了，当进行某些前台操作的时候，系统中进程的个数就会同时增加到一个峰值，超过我们通常的150限额。

处理的方法也比较简单，就是将processes参数设置为一个比较大的取值，就不会出现这个问题了。

SQL> alter system set processes=400 scope=spfile;

System altered

注意，这个参数是不能online修改，要求必须重新启动数据库服务器。

后记：之后经过和开发团队沟通，确定了问题的原因。通常应用所形成的连接数目比较少，但是在使用一种数据库单元测试工具，进行批量数据导入的时候，就会同时开启多个process连接进行导入。当多个组同时进行单元测试的时候，会形成一个连接峰值，超过默认的processes上限。

经验还是：默认值不可全信，要仔细衡量才好。