密码延迟验证导致的系统HANG住

又是一个11g新特性导致的问题。

[@more@]

这个新特性很早之前就研究过,也在其他客户处碰到过类似的问题。从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;

设置该事件后重启数据库即可。

时间: 2024-10-15 22:51:53

密码延迟验证导致的系统HANG住的相关文章

mysql主键的缺少导致备库hang住_Mysql

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题): (1).现

oracle密码错误验证延迟

补充从10g升级到11g之后需要注意的几个密码方面问题: 1. 11g默认开始密码区分大小写,可以通过把参数设置为SEC_CASE_SENSITIVE_LOGON =FALSE 屏蔽 2. 11g密码默认有效期180天,可以通过修改ALTER PROFILE DEFAULT[根据实际的profile] LIMIT PASSWORD_LIFE_TIME UNLIMITED;   注意需要修改密码生效 3. 密码错误验证延迟,可以通过设置EVENT="28401 TRACE NAME CONTEXT

oracle 误杀进程导致rac hang住解决办法

有客户反馈系统hang住,不能归档,需要我们紧急介入分析 节点1日志 出现redo不能归档,redo日志都已经被写满,人工执行了ALTER SYSTEM ARCHIVE LOG CURRENT,数据库就开始把redo全部归档,但是后面产生的redo又不能归档,当redo全部写满之后,数据库有出现大量log file switch (archiving needed)等待  代码如下 复制代码 Tue Sep 24 22:05:37 2013 Thread 1 advanced to log se

彩票系统出现延迟,导致出票失败

今日,有媒体报道称,一位广州的用户通过微信投注的双色球号码中得500万元大奖,开奖后被告知投注失败已经退款.腾讯公司获知此消息后,立即与用户进行了联系并展开调查,同时对该交易记录进行了保全.经查实该报道与事实不符. 腾讯表示,由于彩票系统出现延迟,导致出票失败,退款通知未能及时推送.据用户投注号码,即便交易成功,中奖金额为5元,所谓500万元说法不实. 腾讯声明如下: 6月22日 07:58 用户购买2014070期双色球彩票28元,复式投注,投注号码为08 10 14 15 18 24 31

记一次错误卸载软件包导致Linux系统崩溃的修复解决过程

首先问题产生的缘由很简单,是我一同事在安装oracle一套软件时,按照要求需要binutils软件包的32位版本,然而在Oracle Linux已经装有64位,按理说是可以安装i686的,我猜应该是32位的版本低于这个已有的64位所以导致冲突而安装失败,因此同事就用yum remove binutils,这个命令也奇葩,由于是root权限导致依赖于它的200多个软件包也被卸载,最终导致网络断开,系统崩溃,在vSphere虚拟机上重新启动发现再也起不来.下面看问题: 1. Kernel panic

关于闪回区溢出导致的数据hang(r11笔记第12天)

对于Oracle数据库的闪回区的设置,之前和一个同事和讨论过,总体来说有一些不同的意见. 首先这个闪回区是一个逻辑的概念,闪回区的大小不会严格依赖于磁盘空间的情况,比如磁盘空间目前剩余100G,但是你设置闪回区为200G是没有问题的. 如此一来,和只使用归档参数想比,这个闪回区似乎有一点问题,总体来说闪回区的管理还是比较方便的,可以监控管理闪回区中的归档,闪回日志,备份等的大小. 使用的视图为v$flash_recovery_area_usage,在11g做了简化,为v$recovery_are

Oracle datapump expdp/impdp 导入导出数据库时hang住

   最近在导出schema级别的数据时被hang住,不得不停止当前的导出作业,如果你有类似的问题,请继续往下看.  1.问题描述    导出整个schema时数据库被hang住,如下所示    符号">"是由SecureCRT设定的每300秒发送一次    oracle@Dev-DB-04:~> expdp goex_admin/xxx directory=db_dump_dir dumpfile=gobo2.dmp logfile=gobo2.log schemas=g

Oracle数据库shutdown immediate被hang住的几个原因

实验操作环境:         操作系统:Red Hat Enterprise Linux ES release 4 (Nahant Update 6)                           数据库 : Oracle Database 10g Release 10.2.0.4.0 – Production  32bit 今晚使用shutdown immediate(其实是执行stop_oracle.sh脚本关闭数据库,如下所示)关闭数据库的时候, 1: [oracle@gsp-or