今天有一位兄弟问了一个问题，"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的个人杂货铺