重庆分公司
重庆分公司，新征程启航
为企业提供网站建设、域名注册、服务器等服务
Oracle11g密码延迟认证导致librarycachelock的情况分析
在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试攻击。
创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都网站建设、做网站、宁江网络推广、小程序制作、宁江网络营销、宁江企业策划、宁江品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供宁江建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。
如果遇到这一类问题，可以通过Event 28401关闭这个特性，从而消除此类影响，以下命令将修改设置在参数文件中：
ALTER SYSTEM SET EVENT =
'28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;
出现这类问题非常典型的AWR报告呈现如下，首先在 TOP 5 中，你可能看到显著的 Library Cache Lock 的等待 ，如果用sql查等待时间，则username列为空，以下范例来自11.2.0.3.0版本的真实情况：
在这类情况下，时间模型 - Time Model 中会显示如下指标，其中 connection management call elapsed time 占据了主要的DB Time，这个等待直接表明是在建立数据库连接时产生的：
这类问题，在Oracle的11g中是常见和确定的，在MOS上可以找到相应的记录：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1）此外Oracle 11g开启了密码大小写验证，如果从Oracle 10g升级过来，需要特别的当心这个变化，通过初始化参数SEC_CASE_SENSITIVE_LOGON 可以来控制这个特性。
下面是一个案例：网上摘取下来别人的案例
1，问题来源
以前遇到了问题修改了用户名密码后，发现用新密码登录被hang住的情况，然后整个公司的oa系统彻底瘫痪了，详细状况见以前的记录。
最近学习了oracle11g的新特性密码延迟，才明白问题所在是由于密码延迟导致。
大概情况是：从oracle11g开始，如果用户输入了错误的密码登录，那么随着登录错误次数的增加，每次登录前等待验证的时间也会增加，本意上是为了保护数据库被恶意登录的时候消耗太多db资源导致数据库消耗过高导致数据库服务器出问题，但是这里也引发了问题，如果使用错误密码登录过多，则会影响该用户的正常登录，也就是说密码有验证延迟导致你输入正确的密码登录也需要等待很久。给使用人员的体验就是数据库hang住了（其实你使用其它用户操作数据库完全正常）
2，案例演示
Oracle版本是11g分支11.2.0.1.0：
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0
Connected as timdba@A_VM128
SQL>
| 设置时间显示： SQL> set time on; 07:41:57 SQL> conn timdba/timgood; Connected. 07:42:48 SQL> conn timdba/t;#开始尝试错误密码登录 ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. 07:42:49 SQL> conn timdba/t; #第1次错误登录消耗时间1秒 ERROR: ORA-01017: invalid username/password; logon denied 07:42:51 SQL> conn timdba/t; # 第2次错误登录消耗时间2秒 ERROR: ORA-01017: invalid username/password; logon denied 07:42:52 SQL> conn timdba/t; # 第3次错误登录消耗时间1秒 ERROR: ORA-01017: invalid username/password; logon denied 07:42:54 SQL> conn timdba/t; # 第4次错误登录消耗时间2秒 ERROR: ORA-01017: invalid username/password; logon denied 07:42:57 SQL> conn timdba/t; #第5次错误登录消耗时间3秒 ERROR: ORA-01017: invalid username/password; logon denied 07:43:02 SQL> conn timdba/t; # 第6次错误登录消耗时间5秒 ERROR: ORA-01017: invalid username/password; logon denied 07:43:07 SQL> conn timdba/t; # 第7次错误登录消耗时间5秒 ERROR: ORA-01017: invalid username/password; logon denied 07:43:13 SQL> conn timdba/t; # 第8次错误登录消耗时间6秒 ERROR: ORA-01017: invalid username/password; logon denied 07:43:20 SQL> conn timdba/t;# 第9次错误登录消耗时间7秒 ERROR: ORA-01017: invalid username/password; logon denied 07:43:28 SQL> 07:43:29 SQL> conn timdba/timgood; Connected. 07:43:40 SQL> |
大家可以看到第4次，第5次开始，错误登录验证时间越来越长了。基本每次都延迟多一秒，而后面即使输入了正确密码，也会延迟十几秒了。
而在测试过程中，一旦输入正确密码，验证成功过后，这个错误延时就会清0，从0开始重新计算数字了：
| 08:15:30 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:15:34 SQL> conn timdba/timgood; Connected. 08:15:37 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. 08:15:39 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:15:40 SQL> |
大家进一步扩散下思维，这只是单个session做测试的，如果是线上环境的话，成千上万个会话过来，如果密码都错误了，一起延时的话，按照一个操作多延迟一秒来算，基本要延迟1000秒了，也就是半个小时你登录界面卡在哪里了，这样给客户的体验就是输入了正确密码，结果点击了登录按钮，就卡住了，死活不动弹了，服务器瘫痪了，也就意味着应用系统hang住了。
3，新特性是双刃剑
Oracle的任何一个新特性都能带来性能上的提升和安全上的进一步保证，但是毕竟oracle也只是一个软件software而已，是software就会有bug，甚至被别人利用攻击了。
oracle在11g发布后的几个小版本中，没有给出彻底屏幕密码延迟的方法，但是oracle有强大的其它辅助功能，可以通过设置event事件来处理掉。
4，通过设置Event屏幕密码延迟
这里一般通常设置28401就足够了，如果遇到其它特殊情况，也可以再设置一下，接下来通过设置EVENTS 28401来实现屏蔽密码延迟验证：
ALTER SYSTEM SET EVENT = '28401 TRACE NAMECONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;
alter system set event="10949 TRACENAME CONTEXT FOREVER:28401 trace name context forever, level 1" scope=spfile;
| SQL> set time on; 08:56:22 SQL> ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE; System altered. 08:56:27 SQL> create pfile from spfile; File created. 08:56:29 SQL> |
之后重启oracle数据库生效了。
| 08:56:44 SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. 08:57:05 SQL> startup; ORACLE instance started. Total System Global Area 835104768 bytes Fixed Size 2217952 bytes Variable Size 545261600 bytes Database Buffers 281018368 bytes Redo Buffers 6606848 bytes Database mounted. Database opened. 08:57:46 SQL> |
再次验证错误密码延迟验证，可以看到几乎没有任何延迟了：
| 08:58:28 SQL> conn timdba/timgood; Connected. 08:58:33 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. 08:58:37 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:38 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:39 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:39 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:40 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:41 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied 08:58:42 SQL> conn timdba/t; ERROR: ORA-01017: invalid username/password; logon denied |
网站题目：Oracle11g密码延迟认证导致librarycachelock的情况分析
转载源于：http://cqcxhl.cn/article/jjidgd.html