大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
出處 http://yangtingkun.net/?p=1429
又是一个11g新特性导致的问题。
这个新特性很早之前就研究过,也在其他客户处碰到过类似的问题。从11g开始,如果一个用户使用不正确的密码尝试登录数据库,那么随着登录失败次数的增加,每次登录验证前延迟等待的时间也会增加:
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名与空间、网站空间、营销软件、网站建设、团风网站维护、网站推广。
SQL> SET TIME ON 18:30:54 SQL> 18:30:58 SQL> conn test/test Connected. 18:31:25 SQL> 18:31:25 SQL> conn test/a conn test/a conn test/a conn test/a conn test/a conn test/a conn test/a conn test/test conn test/a ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected TO ORACLE. 18:31:26 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:26 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:26 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:27 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:29 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:32 SQL> ERROR: ORA-01017: invalid username/password; logon denied 18:31:36 SQL> Connected. 18:31:36 SQL> ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected TO ORACLE. 18:31:36 SQL>
可以看到,从第三次密码错误的登录开始,每次延迟时间开始变成2秒、3秒并一次递增。既是这时提供正确的密码登录,会话也会延迟N秒,然后进行验证。不过一旦验证成功,会将失败计数清零,后续的错误登录会重新计数。
不过这只是单一会话尝试失败登录的情况,如果同时存在两个会话,则很快延迟验证时间就会达到10秒、20秒的级别。如果同时大量的连接采用错误的密码,基本上这个用户的登录就会被完全HANG住。
客户的数据库就出现了类似的情况,数据库版本为11.2.0.3 RAC,在数据库中观察,三个节点每个节点的会话数都接近SESSIONS参数设置的上线3000,而后台高级日志已经出现了ORA-20错误。
由于客户系统的关键用户只有一个,因此几乎所有的会话都无法正常的登录到数据库中。而在数据库上发现,大量的会话用户名、EVENT以及PROGRAM都信息都是NULL,这说明这些会话还没有完成验证成功的登录到数据库中。
而当前主机的CPU资源使用并不高,那些已经连接到数据库中的进程也可以正常的工作。尝试使用SYSTEM等其他用户发现可以迅速的登录数据库。
所有这一切都已经说明,当前有一个或多个中间件服务器在使用错误的密码连接数据库,由于密码延迟验证的策略,导致所有后续的连接都被HANG住。
任何一个新特性带来性能或功能上的提高的同时,也会引入相关的bug,显然这个安全性上的考虑,有时候也会带来验证的性能问题,甚至成为用来攻击数据库的一种手段。
之前几次并没有给出彻底屏蔽密码延迟验证的手段,而Oracle最强大之处就在于几乎所有的功能和特性都有对应的开关,通过设置EVENTS 28401可以屏蔽密码延迟验证:
SQL> ALTER SYSTEM SET EVENT = ‘28401 TRACE NAME CONTEXT FOREVER, LEVEL 1’ SCOPE = SPFILE;
设置该事件后重启数据库即可。