在Oracle的11g之前的版本中密码是不区分大小写的（使用双引号强制除外）。在Oracle的11g版本中对此有所增强。从此密码有了大小写的区分，这个大小写敏感特性是通过SEC_CASE_SENSITIVE_LOGON参数来控制的。该参数默认设置为true。
前阵子客户数据从10g迁往11g后，这个参数未修改，新上线第二天全国业务人员输入密码时候参照以前习惯密码全部小写，导致部分业务无法登陆，由于反复尝试登陆导致触发了著名的登陆延迟验证的特性延伸出了library cache lock（Delay after three failed login attempts），导致全线应用响应缓慢假死。当然解决过程当时根据现象，进程达到限制值，做了等待事件模型的分析，发现大量的session都没有成功登陆，很多信息都为null逐判断因为密码延迟验证的原因导致，而密码错误的事情再经过现场验证后发现了大小写敏感的问题。后面就是很熟套的剧情，领导抽了根烟，痛骂了原厂一顿，把此2个特性都关掉后，没有再出现过进程累积的现象。由此问题引发了对密码大小写验证以及密码延迟验证特性的思考.
一：关于sec_case_sensitive_logon的设置
关于sec_case_sensitive_logon参数所关联的密码大小写敏感，我建议在升级数据库系统时候关闭，在新建数据库系统时候关闭。可以配合应用密码策略使用，默认时候可以商讨关闭。
二：密码延迟验证的特性使用与否
关于Delay after three failed login attempts的特性参考yangtingkun的http://blog.itpub.net/4227/viewspace-672925
这个密码延迟特性特性的解决办法有几种，这里我大概描述下：
-
1.设置登陆密码验证失败次数超过几次后锁定用户，该办法可以防止用户反复登陆验证，但是也会增加一定的维护工作
2.通过诊断事件28401关闭密码延迟验证
同时我并不建议用第二种办法，密码延迟验证的特性可以有效遏制恶意破解密码的行为，因此从数据库安全的角度我建议设置密码失败超数锁用户。
关于event 28401
ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE [oracle@ludatou ~]$ oerr ora 28401 28401, 00000, "Event to disable delay after three failed login attempts" // *Document: NO // *Cause: N/A // *Action: Set this event in your environment to disable the login delay // which will otherwise take place after three failed login attempts. // *Note: THIS IS NOT A USER ERROR NUMBER/MESSAGE. THIS DOES NOT NEED TO BE // TRANSLATED OR DOCUMENTED.
