cache buffer chains的一个案例

本文记录了一次解决Oracle数据库CPU利用率异常升高问题的过程。通过排查发现是由于未禁用的测试job导致资源争用,最终通过停止运行中的job并禁用其他job解决了问题。

之前测试库一直很慢,session_wait 一直有cache buffer chains 等待事件,看解释一般都是数据库热块引发的。但一直没找到具体原因,直到昨天实在受不了啦。
忙的手忙脚乱,又是查是否有大表被缓存到buffer cache中,又是google cache buffer chains的原因。
直到中间重启一次数据库,观察cpu利用率在数据库刚启动的时候只有20%,但是很快就升到98%-99%。
查v$session看有几个会话在执行操作,但当时把那几个session误以为是oracle后台进程占用的会话。
当时也不知道哪根筋让想到查dba_jobs_running这个表,发现好多个正在运行的job。

原来是同事将dmp导入到数据库多次做测试没将里面的job禁用掉,而这些job用到的资源都在另外一个用户下,造成了latch争用。
kill掉当前正在运行的job,cpu利用率马上下来了。
接着分别到各用户下执行dbms_jobs.broken;commit;破坏的其他的job

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值