ORA-00020

来源：互联网发布：实时天气预报软件下载编辑：程序博客网时间：2024/04/29 03:37

--ORACLE 11.2.0.3 3节点RAC平台，hp-unix 11.31的系统
--报错信息,ALERT日志

Wed Dec 11 18:02:56 2013Thread 3 advanced to log sequence 2734 (LGWR switch)  Current log# 13 seq# 2734 mem# 0: +DATA_DG/trsendb/redo13_1.log  Current log# 13 seq# 2734 mem# 1: +DATA_DG/trsendb/redo13_2.logWed Dec 11 18:03:02 2013Archived Log entry 4360 added for thread 3 sequence 2733 ID 0x6c1e04fd dest 1:Wed Dec 11 18:06:48 2013ORA-00020: maximum number of processes (2000) 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.Process m000 submission failed with error = 20Wed Dec 11 18:24:35 2013Thread 3 advanced to log sequence 2735 (LGWR switch)  Current log# 14 seq# 2735 mem# 0: +DATA_DG/trsendb/redo14_1.log  Current log# 14 seq# 2735 mem# 1: +DATA_DG/trsendb/redo14_2.log --引起的原因连接数据库时，操作系统的分配给oracle实例的进程数大于数据库参数文件规定的process数 --利用oswbb工具检查数据负载情况均属正常-- 解决办法最直接的办法是就利用alter system set processes=xxxx scope=spfile;来解决，但是这只是临时的办法，我们需要诊断具体的原来来决定

--当ora-20出现时，我们去收集session的信息

sqlplu / as sysdbaset markup html onset pagesize 30spool diagnose_sp.htmlselectp.username "V$PROCESS - OS USERNAME",p.terminal,p.program,s.username "V$SESSION - USERNAME",s.command,s.status,s.server,s.process,s.machine,s.port,s.terminal,s.program,s.sid,s.serial#,p.spidFROM v$session s,v$process pWHERE p.addr=s.paddrorder by p.background desc;spool offexit;

--查看收集的session信息，根据信息可能会出现以下三种情况
1）、有许多v$session.status=inactive...
解决办法:DCD和用户资源限制
可以Doc ID 601605.1 MOS文档里找到"A discussion of Dead Connection Detection, Resource Limits, V$SESSION, V$PROCESS and OS processes"

2）、有许多v$session.program(和可能有许多v$session.status=inactive)条目是同一program...
解决办法：检查应用程序是不是建立在多长时间里放弃连接或者重连来实现响应事件
或者利用DCD和用户资源限制

3）、在v$process上有数据但是在v$session上为空值
这种情况是因为：不管因用户登出，还是kill了会话或者达到了资源限制，oracle SMON(OR PMON)首先清除数据库的资源(如：事务锁，会话锁等；
其次会清除session信息，v$session信息就查询不出来；最后oracle将请求os层面上中断分配给oracle的相关会话；
这个问题可能是OS层面上的问题，需要kill了相关进程 KILL -# (UNIX / LINUX) or ORAKILL (Windows)

--这样的错误，最好在应用层面上解决，如果在数据库层面上处理可能会带来其他的麻烦
--出现ORA-20很久的数据应该去dba_hist_active_sess_history

0 0