今天还想到一个问题，如果导致arch疯涨的进程如果是job引起的？会怎么样子？
通过测试，用昨天的方法也确实能找出相关引起arch疯涨的sid，但是问题就出在kill session这边了。如果是通过job来跑的进程，找到相应的sid kill之，session 的status会变成killed，但是过不了一会（一分钟不到），这个sid又会变成active的状态，且还是执行原来job中的sql，使得arch继续暴涨。和被kill之前唯一不同的，serial#变了。无论kill多少次，job会一直重新激活，一直执行下去。
因此，一旦发生kill掉session之后，还是有疯狂增长的arch，发现是同一个sid，且刚刚kill的时候status是KILLED，之后马上有变成ACTIVE，且根据sid去查sql_text发现是同一个语句，这个时候就要引起注意了！！这个session是不是通过job在跑？
此时可以根据select /*+ rule */ sid from dba_jobs_running;查找是不是有job在跑？job中的procedure中的内容是否是sql_text里面的内容？如果符合，则broken这个job。
因此：dba如果发现大量的arch，必须马上定位这个session，如果发现kill掉了session arch还在异常增长，且还是同一个sid，请考虑是否是job。当然，如果要避免在加载的时候产生少量的arch，就应该：（1）noarch模式下：用append的hints即可；（2）在arch的模式下：用nologging + append。（3）dataguard数据库避免使用nologging参数！