今天有一位兄弟问了一个问题，

pmon清理失败process的频率是多少时间，还是只要process有失败，就清理？

以前感觉就是好像如果kill一个session之后立即执行其他操作，则会立即报错，但v$session中好像还是有这条记录，过了不知道具体多久，才会清除。了解的不系统，因此，接下来就用实验来再说明这个问题。

1.登陆后查看当前session id

2.执行长时间的一个操作，

在此期间查看v$session状态， 可以看出是ACTIVE。

3.未执行任何操作，

此时则是INACTIVE。

4.查看对v$session的STATUS字段描述，

ACTIVE：表示session正在执行SQL。

INACTIVE：session处于INACTIVE状态，并且没有配置限制或者还没有超过配置限制。

KILLED：标记session已被kill。

CACHED：临时缓存session，用于Oracle*XA。

SPINED：一个INACTIVE的session已经超过了配置限制(例如，资源管理器消费者组中的资源限制，或者是用户profile的idle_time值)。这种session将不再允许变为ACTIVE状态。

接下来我们看下SPINED和KILLED状态。

(1) SPINED

查看当前用户使用的profile以及idle_time限制，当前用户使用的是DEFAULT的profile， DEFAULT的profile中idle_time默认值是UNLIMITED， 为了验证说明，为用户创建一个新的profile，并设置idle_time为60(秒)， 登陆，等待一分钟之后，在查询状态，奇怪，怎么还是INACTIVE？ 原因就是因为只有resource_limit参数设置为true时，profile中有关资源的限制才会生效， 默认则为false， 现在改为true，注意从alert日志中可以看出其默认执行的是scope=both， 再试一次，状态仍旧未变，原来是之前设置idle_time，未注意时间单位，60表示60分钟不是60秒(profile中和时间相关的参数均为分钟，不是秒)，改一下设置为1分钟， 等待一分钟，再次查询，发现已经是SPINED状态了， 此时用户再次执行操作，会提示错误， 但如果之前有未退出的用户，idle_time=1的限制不会生效。

(2) KILLED

找到用户对应的sid和serial#值，执行alter system kill session操作，以及kill -9 spid，此时状态变为了KILLED， 此时若不做任何操作，v$session中这条KILLED的记录会长时间保存， 直到用户执行操作才会报错， 此时再次查询v$session，发现记录已被清空了，说明此时PMON进程做了一些process清理的操作。

难道只有当做一些操作的时候，才会主动触发PMON进程清理已经KILLED状态的process？查了一些资料，发现其实PMON进程有主动唤醒的机制，间隔时间是受_pkt_pmon_interval隐藏参数控制，默认是50分钟，

为了验证方便，我们将值改小， 改动之前设置， 改动之后设置， ISMODIFIED含义， 执行alter system kill session和kill -9 spid， 一分钟左右，v$sesson中这条KILLED的记录就被清除了， 说明了PMON进程一分钟左右就被唤醒，执行了相应的清理操作。

总结：

因此针对开始的问题，

pmon清理失败process的频率是多少时间，还是只要process有失败，就清理？

答案就是进程失败，PMON清理的频率受隐藏参数_pkt_pmon_interval控制，默认值是50分钟，如果靠PMON主动来做清理则需要等待50分钟，但若此时在session中再次执行任意操作，则会立即触发PMON进程进行清理操作。

欢迎关注我的个人微信公众号：bisal的个人杂货铺