Oraclebug的故障排查过程思考.docx
《Oraclebug的故障排查过程思考.docx》由会员分享,可在线阅读,更多相关《Oraclebug的故障排查过程思考.docx(9页珍藏版)》请在第一文库网上搜索。
1、一次Orac1ebug的故障排查过程思考的问题重现解决AhA【导读】本文是前文一次OraC1ebug的故障排查过程思考的后续。对原文中的问题现象“一套十几个TPS的系统被执行2分钟的夜维搞挂了“在生产环境中进行了重现以及解决。在一次OraCIebug的故障排查过程思考(点击阅读)这个问题排查过程中,当时和同事们一起猜测、实验、论证,昨天有幸,经过了精心设计,在生产环境中,进行了问题重现,以及解决的部分验证。为了统计数据,在每次测试前后,各打印次AWRSnapshoto笫一次测试1.应用:使用旧的夜维(无批量提交,虽然de1ete操作一次删除IOOOO条,但是会在删除所有数据(20万)完成的时候
2、,才会做Commit,约需要2分钟,即需要让相应数据和回滚表空间的数据块处于事务进行中状态约2分钟)。2 .数据库:未设置IOO19,存在BUg13641076的bugfix,未修复BUg19791273o3 .执行过程:当夜维执行到第10次左右的IOOOo条de1ete操作,应用的响应时间开始变长,数据库CPUid1e最低降到了60%左右了,正常时间段,CPUid1e一般为80%-90%左右的。4 .数据:这次夜维执行,22:10-22:12,总计2分钟左右,检索对应业务的UPdate语句逻辑读,从下图可以看出,相比其他小时段,增长了将近IOOo倍,从SQ1AWR看,这条UPdate语句的逻
3、辑读,大约是224986.5021057557,一条使用唯一索引的UPdate语句执行计划,已经是很高效了,22万的逻辑读,就很不正常了,和BUg19791273的现象PoOrUPDATESQ1performanceduetospacesearchcacheforupdatesonASSMsegment,很是相像的,一.1.-1)虽然没出现故障当天CPUid1e为0的现象,但是有所下降,而且业务UPdate语句的逻辑读,如此之高,应该算是复现了这个问题。第二次测试1 .应用:使用旧的夜维,同时,业务切换至备份集群,重启备集群的连接池和应用,以让Bug13641076描述的将spacesearc
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Oraclebug 故障 排查 过程 思考