祸不单行.
1.故障1
半夜收到wang.rui电话,数据库hang住了一样,所有的redolog都是active,新加redo马上就会写完变成active状态,无论多大.
思路:
判断数据库是不是还活着,hang analyze.或者看归档的切换频率,检索告警看看有没有价值的信息
这类东西能让redo这么繁忙,一般都是大事务或者并发大事务,所以可以挖下归档看看操作
既然有观点2了,那么job和schedul是跑不掉检查的
看看数据库的等待事件以及session block情况(别问我为啥要看阻塞,嘿嘿)
故障1最终话费了大概前后几分钟,检测出来,是由于大事务被撤销,产生大量回滚,同时oracle产生了128个并行进程在恢复.这与参数fast_start_parallel_rollback有关,默认为low.由于大量并行的恢复,导致io瓶颈的产生,同时undo争用厉害,改为high是不行了,改为false后,所有开销马上下降.当然这里存在了一个疑问点,默认是low的情况下并行进程是数量应该是cpu_count*2,应该为64才对,为啥我这里128??
2.故障2
清早收到数据库进程阻塞故障,原因不明,所有进程hang住.10205版本数据库linu平台.
检测发现cpu耗尽,内存耗用光,采集了一些os信息后重启恢复了系统,检测后来的信息发现有css的等待,数据库为单机,未采用grid,比较奇怪,跟踪后发现类似bug,Bug 10024824.怀疑大量session因为此bug被hang住把cpu耗光了….主要是发现oracle也没啥很异常的sql波动…准备打补丁.
