ORACLE11g新特性-密码区分大小写与延迟失败登录
从11g开始，ORACLE的用户密码区分大小写，在11g之前的版本，密码是不区分大小写的，这也是11g的一个新特性， 在ORACLE 11g版本中，密码改成了Secure Hash Algorithm（SHA-1）算法，而不是以前的基于Data Encryption Standard（DES）的散列算法，同时，ORACLE也推出了延迟失败登录新特性， 如果某个用户试图多次使用错误的密码连接数据库，在第三次失败之后，ORACLE将延迟对客户的响应，即使是不同IP地址或主机发出的错误密码登录也会被延迟响应，ORACLE把延迟响应时间设置最多10秒以保证数据库的安全，但是row cache lock等待事件也伴随着出现。
下面是一个朋友的数据库由于一套废弃的应用程序使用大写的密码连接11g（用户密码小写）的数据库，导致row cache lock等待事件，严重影响正常业务系统运行的案例，以下是她对此事件的描述及她的处理方法：
在有一天开会的时候，开发的同事在给我们演示在数据库上执行部署的脚本（主要为给表增加新字段）时，发现超级慢，后来也没有演示完毕。随后晚上我将数据重新导入这个库发现也超级慢，正常的话一般要1个小时就能导完，当天晚上我发现impdp导了4个小时。第二天我查看发现：
1、查看等待事件发现：
select * from v$session_wait where wait_class ! ='Idle';
2、根据sid查看spid来看os的进程是哪个？
select v$session.username,v$session.status,v$process.spid from v$session, v$process where v$session.PADDR=v$process.addr and sid=264;
3、查看sid为264的是哪个用户？
4、ps 查看
5、下午的时候查看：
她查看metalink，认为这是个BUG。
Bug 9776608 Hang from concurrent login to same account with a wrong password This note gives a brief overview of bug 9776608. The content was last updated on: 03-FEB-2012 Click here for details of each of the sections below. Affects: Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions BELOW 12.1 Versions confirmed as being affected •11.2.0.1 •11.1.0.7 Platforms affected Generic (all / most platforms affected) Fixed: This issue is fixed in •12.1 (Future Release) •11.2.0.2 (Server Patch Set) •11.1.0.7 Patch 42 on Windows Platforms Symptoms: Related To: •Hang (Process Hang) •Waits for "row cache lock" •Security ( Authentication / Privileges / Auditing ) Description A hang problem can occur when many concurrent logins to the same user account are taking place, and some are with the wrong password. Symptom is that this account no longer accepts any login, but other accounts still allow login. Rediscovery Notes: Hang during login. A Systemstate will show an X request blocking in this short stack, because of an S wait ahead of it and another S behind it on the request queue: sskgpwwait()< -ksliwat()<-kslwaitctx()<-kqrigt()<-kqrLockAndPinPo() <-kqrpre1()<-kqrpre()<-kziavua()<-kpolnb()<-kpoauth()<-opiodr() HOOKS PSE:B107 "WAITEVENT:row cache lock" SUPERCEDES:9720182 LIKELYAFFECTS XAFFECTS_11.1.0.6 XAFFECTS_V11010006 AFFECTS=11.1.0.6 XAFFECTS_11.1.0.7 XAFFECTS_V11010007 AFFECTS=11.1.0.7 XAFFECTS_11.2.0.1 XAFFECTS_V11020001 AFFECTS=11.2.0.1 XPRODID_5 PRODUCT_ID=5 PRODID-5 RDBMS XCOMP_RDBMS COMPONENT=RDBMS TAG_HANG TAG_SEC HANG SEC FIXED_11.2.0.2 FIXED_12.1.0.0 FIXED_WIN:B107P42 Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support. References Bug:9776608 (This link will only work for PUBLISHED bugs) Note:245840.1 Information on the sections in this article
她对这个BUG的理解是：在11.1的版本中，如果有2个或者多个应用并发的去连接后台的数据库的时候，并且有一路连接的链接是失败了（可能密码是不对的）的时候，会有这个等待事件，并且在查询第5项的时候发现有2个sid一直在，所以感觉应该可能是有两路应用都在链接这个数据库。
6、联系开发人员，得到应用连接的信息
昨天下午和开发人员联系，说了我的想法，在快下班的时候，他们终于发现此时连接这个数据库的有2个应用（一个为正常的连接，另一个早起为0.5版本的连接没有停，并且密码对不对），待将早期的连接停掉之后，问题解决。
以上案例就是典型的11g区分密码大小写和延迟失败登录新特性导致的故障，也咨询了下资深的ORACLE专家，他的意思是说ORACLE不会说这是个BUG，ORACLE这样做是为了防止有人恶意破解数据库密码，但是这种对全局都有影响的等待事件也非常的可怕，不知道ORACLE在下个版本对此会不会推出什么好的解决方案。
还有一个没这么严重的案例，发生在我参与开发的一个项目上，负责这个项目的开发人员都是上海的一家开发公司派到北京的，人员流动比较大，总有一些新人参与开发，有开发环境（Windows Server 2008，11.2.0.1.0版本数据库）、测试环境（OEL5.7，11.2.0.2.0版本数据库）和试运行环境（OEL5.7，11.2.0.2.0版本数据库）3套环境，我负责的是测试环境和试运行环境，开发环境的维护我也有参与，但基本都是开发人员自己管理，由于开发人员创建用户时，密码习惯是大写（而且不指定默认表空间），多次要求开发人员修改用户密码为小写（只有部分用户改为了小写），而甲方要求密码小写，而且我的规划是每个用户都有单独的默认表空间，这样每次同步数据时，都需要转换表空间，还好数据泵对表空间的转换很方便。
这样除了维护起来比较麻烦外，开发人员也比较纠结，每次测试或发布程序新版本时，都会问密码大写还是小写，而且也总配错密码。
最近项目马上结项，工作量比较大，出现用户无故被锁住的情况，帮开发人员解了好几次锁，目前这个项目的数据库没有设置概要文件，所有用户的概要文件都是默认的，也就是错误密码登录数据库10次，用户就会被锁住。
SQL> select * from dba_profiles where RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS'; PROFILE RESOURCE_NAME RESOURCE LIMIT ---------- ----------------------- -------- --------------- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
开发人员现在也有了经验，只要用户被锁住，就去查看程序的配置，并修改正确的密码，还好试运行环境一直未发生过这类问题。
以下是我对密码大小写做的实验。
1、创建密码大写的用户
SQL> create user dbdream identified by DBDREAM default tablespace users; User created. SQL> grant connect,resource to dbdream; Grant succeeded.
2、修改概要文件信息，设置失败登录3次锁住用户。
SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 3; Profile altered.
3、使用大写密码登录
SQL> conn dbdream/DBDREAM Connected.
可以正常登录，没有问题。
4、使用小写密码登录4次。
SQL> conn dbdream/dbdream ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL> conn dbdream/dbdream ERROR: ORA-01017: invalid username/password; logon denied SQL> conn dbdream/dbdream ERROR: ORA-01017: invalid username/password; logon denied SQL> conn dbdream/dbdream ERROR: ORA-28000: the account is locked
使用小写的密码报错，无法登录数据库，而且在失败登录3次后，lock住用户，使用该用户第4次登录时，用户已经被锁住，报ORA-28000错误。
在11g的数据库中，密码大小写受SEC_CASE_SENSITIVE_LOGON参数的限制。
SQL> show parameter SEC_CASE_SENSITIVE_LOGON NAME TYPE VALUE ------------------------ ----------- ------ sec_case_sensitive_logon boolean TRUE
该参数默认设置为TRUE，也就是区分密码大小写，将该参数修改为FALSE，在用户登录是就不会区分大小写，这是个动态参数，修改后可以立即生效。
SQL> alter system set sec_case_sensitive_logon=false; System altered.
再次使用小写密码登录dbdream用户，可以登录，在SEC_CASE_SENSITIVE_LOGON参数为FALSE的时候，虽然用户登录不区分大小写，但是数据库所记录的用户密码是区分大小写的，ORACLE这样做是为了在启用SEC_CASE_SENSITIVE_LOGON参数时可以再次区分密码大小写。
SQL> alter user dbdream account unlock; User altered. SQL> conn dbdream/dbdream Connected.
此时修改dbdream用户的密码为Dbdream，然后尝试用大写和小写密码登录，都是没问题的，数据库已经不区分大小写密码登录了。
SQL> alter user dbdream identified by Dbdream; User altered. SQL> conn dbdream/dbdream Connected. SQL> conn dbdream/DBDREAM Connected..
将SEC_CASE_SENSITIVE_LOGON参数设置为TRUE，再次使用全大写、全小写、正确密码登录dbdream用户，验证在SEC_CASE_SENSITIVE_LOGON参数为FALSE时，数据库记录用户的密码是否区分大小写。
SQL> alter system set SEC_CASE_SENSITIVE_LOGON=true; System altered. SQL> conn dbdream/dbdream ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL> conn dbdream/DBDREAM ERROR: ORA-01017: invalid username/password; logon denied SQL> conn dbdream/Dbdream Connected.
在11g的数据库中，对拥有SYSDBA和SYSOPER角色的用户密码是否区分大小写是受创建密码文件时的ignorecase参数控制，默认是n，即区分密码大小写。
[oracle@dbdream ~]$ cd $ORACLE_HOME/dbs [oracle@dbdream dbs]$ mv orapwdbdream orapwdbdream_bak [oracle@dbdream dbs]$ orapwd file=orapwdbdream entries=10 password=DBDREAM ignorecase=n
远程登录数据库，验证密码是否区分大小写。
C:Usersstream>sqlplus sys/dbdream@dbdream SQL*Plus: Release 11.2.0.1.0 Production on 星期六 3月 31 11:30:12 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. ERROR: ORA-01017: invalid username/password; logon denied 请输入用户名: C:Usersstream>sqlplus sys/dbdream@192.168.78.100/dbdream C:Usersstream>sqlplus sys/DBDREAM@dbdream as sysdba SQL*Plus: Release 11.2.0.1.0 Production on 星期六 3月 31 11:33:09 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL>
在重建密码文件，设置ignorecase为y，再次远程登录验证登录时是否区分密码大小写。
[oracle@dbdream dbs]$ rm -rf orapwdbdream [oracle@dbdream dbs]$ orapwd file=orapwdbdream entries=10 password=DBDREAM ignorecase=y C:Usersstream>sqlplus sys/dbdream@dbdream as sysdba SQL*Plus: Release 11.2.0.1.0 Production on 星期六 3月 31 11:35:35 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> C:Usersstream>sqlplus sys/DBDREAM@dbdream as sysdba SQL*Plus: Release 11.2.0.1.0 Production on 星期六 3月 31 11:36:11 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL>
可以看到在创建密码文件时，如果指定ignorecase参数值为y，在有用SYSDBA,SYSOPER角色的用户登录数据库时，是不区分密码大小写的。
还有一种情况，从11g以前的版本迁移过来的用户，密码不区分大小写，保留以前的风格，可以在dba_users视图中查看这部分信息。
SQL> select username,password_versions from dba_users; USERNAME PASSWORD ------------------------------ -------- OUTLN 10G 11G SYS 10G 11G SYSTEM 10G 11G FLOWS_FILES 10G 11G APEX_030200 10G 11G CTXSYS 10G 11G SCOTT 10G 11G DBDREAM 10G 11G OGG 10G 11G ARRANGEMENTS 10G 11G ANONYMOUS MDDATA 10G 11G APEX_PUBLIC_USER 10G 11G MDSYS 10G 11G ORDSYS 10G 11G EXFSYS 10G 11G DBSNMP 10G 11G WMSYS 10G 11G APPQOSSYS 10G 11G ORDDATA 10G 11G XDB 10G 11G ORDPLUGINS 10G 11G SI_INFORMTN_SCHEMA 10G 11G ORACLE_OCM 10G 11G XS$NULL 10G 11G DIP 10G 11G SPATIAL_CSW_ADMIN_USR 10G 11G SPATIAL_WFS_ADMIN_USR 10G 11G 28 rows selected.
如果有用户的PASSWORD_VERSIONS列只有10G或者9i，表示这个用户是由10G或9i的数据库创建或最后修改的，不受密码大小写限制，也可以理解为DBA_USERS视图里面用户的PASSWORD_VERSIONS列的值不包含11G，这个用户在登录时就不受密码大小写限制，但是只要修改这个用户的密码，那么在登陆时就区分大小写了，而且PASSWORD_VERSIONS也会被修改为11G。
ORACLE11g新特性-密码区分大小写与延迟失败登录：等您坐沙发呢！
发表评论
