查找疯狂增长的arch-续

今天还想到一个问题,如果导致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参数!

相关文章

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据