暂无图片
分享
文成
2019-03-13
数据库进程数异常

os: SunOS bjdb03 5.10 Generic_144488-04 sun4u sparc SUNW,SPARC-Enterprise

database version :Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production


数据库出现客户端连接不上,查看alert日志

Wed Mar 13 09:21:50 2019

ORA-00020: No more process state objects available

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 J002 submission failed with error = 20

kkjcre1p: unable to spawn jobq slave process

Errors in file /export/home/u01/app/oracle/diag/rdbms/wcdma/wcdma/trace/wcdma_cjq0_25517.trc:

Wed Mar 13 09:22:20 2019

TABLE WCDMA.CLT_PM_W_ERIC_UPLINKBASEBANDPO: ADDED INTERVAL PARTITION SYS_P12772244 (71096) VALUES L

ESS THAN (TO_DATE(' 2019-03-13 08:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))

Wed Mar 13 09:22:55 2019

ORA-00020: No more process state objects available

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 W000 submission failed with error = 20

Wed Mar 13 09:24:41 2019

Thread 1 cannot allocate new log, sequence 511057

Wed Mar 13 09:34:27 2019

ORA-00020: maximum number of processes 800 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.


此时查看 v$process 为738个进程,参数process进程数设置为800.

以下语句查询结果为380

select count(*) from v$process where addr not in (select paddr from v$session);


杀掉这些进程,客户端可以正常连接。总体进程维持在400左右。


问题点:

  1. pmon为何没有清理掉这380个没有会话的进程。

  2. 是否有参数设置pmon清除僵尸进程的条件,比如空闲时间之类的。


收藏
分享
10条回答
默认
最新
文成

通过操作系统 truss 这些进程,发现基本都是sleep的状态

# truss -p 24361

    *** SUID: ruid/euid/suid = 502 / 501 / 501  ***

read(22, 0x10C39D1B6, 2064)     (sleeping...)


暂无图片 评论
暂无图片 有用 0
Moone

pmon只负责清理sesion,删除v$session记录,进程是调用OS来完成的;

这种情况要从OS层面分析原因,看看这些进程有没有共性,是否网络层面挂死了等等。

暂无图片 评论
暂无图片 有用 0
文成

做了个实验,使用alter system kill session 杀掉一个会话,对应的session.status 标记为killed,该session的paddr发生了改变,但是对应的process还是存在。

跟踪整个过程中该进程,没什么动静,也没有收到数据库发的终止指令。

# truss -p 10446
    *** SUID: ruid/euid/suid = 502 / 501 / 501  ***
read(18, 0x10C39D936, 8208)     (sleeping...)

如何去跟踪数据库是否给操作系统发送了指令,以及操作系统是否收到指令并清理了对应的进程呢


暂无图片 评论
暂无图片 有用 0
Moone

如果你在kill session时做truss,这个process杀不掉是正常的,你可以尝试直接kill session后,客户端退出然后看v$process能不能清理。

如果这样没有问题,那这些残留的process一般是因为client端异常导致的,可以坚持是否网络存在防火墙,是否会在不活动超时后断开数据库连接?

可以通过DCD设置解决:

sqlnet.ora文件加参数:

SQLNET.EXPIRE_TIME = <MINUTES>   

分钟数要小于防火墙的空闲超时时间。

暂无图片 评论
暂无图片 有用 0
文成

按照回复设置了以下参数。

sqlnet.ora文件加参数:

SQLNET.EXPIRE_TIME = 10

查看服务器没有开启防火墙,也上传了巡检脚本。


还发现一些异常

  1. 另外一个数据库跟本数据库做了dblink,另外的数据当前没有任务在访问dblink,本数据库出现将近30个inactive超过10分钟的session一直不清除,查看v$session.last_call_et都超过600.

  2. 还是会出现一些在v$process中可以查到,但是在v$session查不到的进程,并且数量慢慢增多。估计过几天,又会超过max_process



暂无图片 评论
暂无图片 有用 0
文成

巡检报告名为  WCDMA_20190313151424_智能巡检报告

暂无图片 评论
暂无图片 有用 0
文成

今早过来发现数据库进程数还是涨上来了,其中在process中可以查询到,但是在session查询不到的进程有200多个,另外的数据库连接过来的inactive session有18个,整体进程数目接近600个。

实时事务数目为5个。

暂无图片 评论
暂无图片 有用 0
章芋文

一般kill session后会出现这种情况,但是一般不会出现几百个的情况。

首先请检查是否存在频繁kill session的操作,和应用建立连接、断开连接的方式是否规范;

其次,临时将数据库的process参数调高,避免应用出错。

最后,提供一个清理process的脚本:

#!/bin/sh
. /home/oracle/.profile
sqlplus -s / as sysdba <<EOF
set pagesize 0 
set long 90000 
set feedback off 
set echo off 
spool killed_pid.txt
select spid from v\$process where program!= 'PSEUDO' and addr not in (select paddr from v\$session) and addr not in (select paddr from v\$bgprocess) and addr not in (select paddr from v\$shared_server);
spool off
exit;
EOF
echo ''>1.log
echo ''>kill_pid.sh
cat killed_pid.txt| while read line
do
if `ps -ef|grep $line|grep LOCAL=NO`
then echo `ps -ef|grep $line|grep LOCAL=NO`>>1.log
echo "kill -9  $line">>kill_pid.sh
fi
done
暂无图片 评论
暂无图片 有用 0
文成

没有kill session的操作,但是该服务器网卡之间故障过,怀疑网络问题导致 。

实施方案

  1. 定期清除找不到会话的 进程

  2. 清理执行时间超过2个小时的inactive会话

  3. 增大process数目


暂无图片 评论
暂无图片 有用 0
文成
问题已关闭: 问题已经得到解决
暂无图片 评论
暂无图片 有用 0
回答交流
提交
问题信息
请登录之后查看
邀请回答
暂无人订阅该标签,敬请期待~~
暂无图片墨值悬赏