library cache lock等待事件
问题背景,客户反馈DB服务器cpu异常高
1> 查看AWR报告
大量library cache lock等待
大量library cache lock导致登陆hang住,时间全部消耗在了 connection management call elapsed
先查杀等待会话
1 select 'alter system kill session ''' || a.sid || ',' || serial# || ''';' 2 from v$session a 3 where a.username='ECOLOGY' 4 AND a.STATUS='ACTIVE' 5 and event in('library cache lock','library cache: mutex X')
3>
对于正常的系统,由于密码的更改,可能存在某些被遗漏的客户端,不断重复尝试使用错误密码登录数据库,
从而引起数据库内部长时间的”library cache lock”或”row cache lock”的等待,这种情形非常常见。
这种现象在Oracle 10.2和11.1中体现的等待事件为:”row cache lock”,而在Oracle 11.2中体现的等待事件为:”library cache lock”。
在 Oracle 11g 中,为了提升安全性,Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是,如果用户输入了错误的密码尝试登录,
那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击。
(确实有错误的数据库连接)
但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的 Library Cache Lock的等待,这种情形非常常见。
如果遇到这一类问题,可以通过Event 28401关闭这个特性,从而消除此类影响,以下命令将修改设置在参数文件中:
1 ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;
分类:
Oracle
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了