ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Processes参数设置引起的故障解决一例

Processes参数设置引起的故障解决一例

原创 Linux操作系统 作者:realkid4 时间:2011-05-04 19:56:54 0 删除 编辑

 

很多情况下,我们是不推荐修改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:

 

 

这个代码片段报错两个。首先在下午24425秒的时候,报错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上限。

 

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

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-694446/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7753658