在Oracle 11 g中,为了提升安全性,甲骨文引入了“密码延迟验证”的新特性。这个特性的作用是,如果用户输入了错误的密码尝试登录,那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击。
但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的库缓存锁的等待,这种情形非常常见。
如果遇到这一类问题,可以通过事件28401关闭这个特性,从而消除此类影响,以下命令将修改设置在参数文件中:
改变系统设置事件=
28401年跟踪的名字永远上下文,一级的范围=SPFILE;
出现这类问题非常典型的心田报告呈现如下,首先在前五名中,你可能看到显著的库缓存锁的等待,如果用sql查等待时间,则用户名列为空,以下范例来自11.2.0.3.0版本的真实情况:
以前遇到了问题修改了用户名密码后,发现用新密码登录被挂住的情况,<强>然后整个公司的oa系统彻底瘫痪了,详细状况见以前的记录。
最近学习了oracle11g的新特性密码延迟,才明白问题所在是由于密码延迟导致。
大概情况是:从oracle11g开始,如果用户输入了错误的密码登录,那么随着登录错误次数的增加,每次登录前等待验证的时间也会增加,本意上是为了保护数据库被恶意登录的时候消耗太多db资源导致数据库消耗过高导致数据库服务器出问题,但是这里也引发了问题,如果使用错误密码登录过多,则会影响该用户的正常登录,也就是说密码有验证延迟导致你输入正确的密码登录也需要等待很久。给使用人员的体验就是数据库挂住了(其实你使用其它用户操作数据库完全正常)
<强> 2,案例演示
<强>甲骨文版本是11 g分支11.2.0.1.0:
连接到数据库Oracle 11 g 11.2.0.1.0 Enterprise Edition版本
联系timdba@A_VM128
完成;
设置时间显示:
完成;设置时间> <强>大家可以看到第4次,5次第开始,错误登录验证时间越来越长了。基本每次都延迟多一秒,而后面即使输入了正确密码,也会延迟十几秒了。
<>强而在测试过程中,一旦输入正确密码,验证成功过后,这个错误延时就会清0,从0开始重新计算数字了:
08:15:30完成;康涅狄格州timdba/t;
错误:
ora - 01017:无效的用户名/密码;登录了
08:15:34完成;康涅狄格州timdba/timgood;
连接。
08:15:37完成;康涅狄格州timdba/t;
错误:
ora - 01017:无效的用户名/密码;登录了
警告:你不再连接到ORACLE。
08:15:39完成;康涅狄格州timdba/t;
