今天有一位兄弟问了一个问题，
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进程进行清理操作。
