Oracle latch:library cache 导致 数据库挂起 故障
来源:互联网 发布:mac docker 仓库地址 编辑:程序博客网 时间:2024/05/01 04:20
这个一个普通的周四,和往日一样,到公司,开电脑,收邮件。 还没几分钟,收到一条手机告警短信,看了一下,放那没管了,一天能收到上百条的告警信息,麻木掉了,过了几分钟,又收到一条相同库的报警,还是看了一眼,不过此时心里已经提高警惕了,第三次收到报警,知道这个库肯定出问题了,迅速连内网。
Sun 5.1 的系统,DB 11.2.0.2. 登陆的过程是个苦逼的过程,登陆30多秒才登陆成功,不用查看就知道CPU 肯定100%了。
oracle@h25k06dc$vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi pofr de sr m5 m6 m7 m1 in sycs us sy id
0 0 0120080864 63113000 122 721 266 175 174 0 0 5 24 0 5 1590 7847 3308 9 1 90
308 0 0117751600 66781304 194 616 0 9 9 0 0 3 0 1 3 2444 81080 46681 97 3 0
305 0 0117752440 66782280 160 556 0 6 6 0 0 5 0 0 4 2430 84445 40509 97 3 0
310 0 0117751872 66780480 165 718 0 2 2 0 0 3 0 0 3 2399 74438 42603 97 3 0
307 0 0117752296 66782264 77 344 0 3 2 0 0 3 0 0 3 2319 82768 42063 97 3 0
第一列300+的数字很显眼,一般几十就很紧张了。不过还见过600多的,也就没什么大惊小怪,按步骤来,看等待事件:
select event,count(*) fromv$session group by event;
命令敲下去,几分钟都没反应,不过不能继续等下去,新开了一个窗口,准备做个hanganalyze,杯具的同样没反应。
等了一会,还是没反应,这种事情遇到多了,也不那么慌了,期间还接了局方的几个电话,挂了电话,继续奋斗,开来只能用最后一招了,kill 进程。
本打算用一条命令搞定的:
ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9
保险期间,先ps了一下:
ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'
返回几百个,有点多,一般来说,如果数据能正常连接和操作,最好先定位出具体的session,在把这个session对应的进程kill 掉就ok了,明显今天早上人品欠佳,定位不出来。
这里LOCAL=NO 的进程太多,不能全部kill 掉,也是没办法,一次kill 部分,看可能缓解一下。
每次随机的kill 一批,kill 到第三批的时候,总算有反应了。
oracle@h25k06dc$vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi pofr de sr m5 m6 m7 m1 in sycs us sy id
0 0 0 120078656 63119016 122 722 266 176 176 00 5 24 0 5 1597 7899 3333 9 1 90
0 0 0 118483144 67508104 61 1159 0 0 0 0 0 220 0 22 5349 28461 13297 55 4 42
0 0 0 118487648 67513760 38 726 0 0 0 0 0 0 0 0 0 4435 24430 10103 52 4 44
0 0 0 118488136 67514264 36 482 0 0 0 0 0 7 0 0 7 3451 22461 10015 51 3 47
0 0 0 118489392 67515480 58 630 0 0 0 0 0 1 0 0 14087 29228 12237 49 4 47
看了一下时间,处理过程大约花了20分钟,有点长,反应速度还需要提高。迅速创建了一个快照,用来分析故障原因:
这里event 很明显,latch:library cache。
当我们对包,存储过程,函数,视图进行编译的时候,Oracle就会在这些对象的handle上面首先获得一个library cache lock,然后再在这些对象的heap上获得pin,这样就能保证在编译的时候其它进程不会来更改这些对象的定义,或者将对象删除。
当一个session对SQL语句进行硬解析的时候,这个session就必须获得librarycache lock。 这里AWR也比较明显,硬解析过高。
从v$active_session_history视图里抓了latch: library cache 的session 及SQL,有3个SQL 没有使用绑定变量,导致硬解析过高。
SQL提交给运维,继续关注数据库,说不定这库哪天又CPU 100%了。
关于library cache lock,之前单独写过一篇blog,参考:
OracleLibrary Cache Lock 解决思路
http://blog.csdn.net/tianlesoftware/article/details/7956996
---------------------------------------------------------------------------------------
版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!
Skype: tianlesoftware
QQ: tianlesoftware@gmail.com
Email: tianlesoftware@gmail.com
Blog: http://blog.csdn.net/tianlesoftware
Weibo: http://weibo.com/tianlesoftware
Twitter: http://twitter.com/tianlesoftware
Facebook: http://www.facebook.com/tianlesoftware
Linkedin: http://cn.linkedin.com/in/tianlesoftware
- Oracle latch:library cache 导致 数据库挂起 故障
- latch:library cache
- library cache —— latch: library cache
- Library Cache Latch和Shared Pool Latch
- shared pool latch和library cache latch
- library cache latch等待事件
- 故障排除:Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)
- oracle library latch
- oracle错误密码导致library cache lock
- 归档日志满导致数据库挂起故障处理
- latch: cache buffers chains故障处理总结
- Oracle优化 latch free问题Result Cache:RC Latch引起数据库缓慢
- [Oracle]--Library cache lock 故障解决一例 oracle10g
- library cache —— latch: shared pool
- latch:library cache 引起的数据库短暂hang(BUG 7122093)
- latch: cache buffers chains等待导致CPU100%
- oracle latch:row cache object,latch free案例处理
- latch: cache buffers chains故障处理总结(转载)
- ArcGIS JavaScript API开发的地图—重新布局
- 句柄和指针的区别和联系是什么?[英国某著名计算机图形图像公司面试题]
- C++ 二维数组与元素为指针的数组
- 2012,当我们谈论移动互联网创业时,我们在谈论些什么?
- 程序员如何保持优秀 转
- Oracle latch:library cache 导致 数据库挂起 故障
- Expression Blend实例中文教程系列文章汇总
- 在windows 7 上为 sqlserver 2008 启用远程访问
- 到底在哪个数据上被坑了 。。。NYOJ 104
- hdu1540 线段树之区间左右连续询问
- Hibernate 检索策略
- win7 防火墙开启ping
- c++对象序列化初步探讨
- 软件开发设计阶段