当前位置:数据库 > Oracle >>

oracle 11g bug:修改普通用户密码挂住,所有客户端均连接不上,生产中断分析

oracle 11g bug:修改普通用户密码挂住,所有客户端均连接不上,生产中断分析
 
环境:
       Oracle 11.2.0.2 RAC  for  IBM AIX 6.1  2节点 
 
一条简单的修改用户密码SQL语句 :
 
alter user ** identified by ***;
 
竟然会挂住在那,此时所有的客户端(.net架构短连接)均无法连接,也是连接出不来,也不报错。
 
此时做了个10046,生成了个跟踪文件如 附件。
 
 
后重启了2个节点数据库后,用了不到5分钟,又出现所有客户端无法连接数据库。
 
 
FYI:
相关bUG 
 
 
Description
 
    In 11g there is an intentional delay between allowing failed logon
    attempts to retry. For some specific application types this can cause
    a problem as the row cache entry is locked for the duration of the
    delay . This can lead to excessive row cache lock waits for DC_USERS
    for specific users / schemas .
     
    This "fix" allows the logon delay to be disabled in 11.2.0.1 onwards
    by setting event 28401 in the init.ora.
    eg:
        event="28401 trace name context forever, level 1" # disable logon delay.
    This "event" will disable the logon sleep delay system-wide, 
    ie. it will affect all user accounts, system-wide, and so should be used
        with extreme caution.
     
    Example scenario:
     A mix of correct and incorrect logon attempts occur for user X
     On each successive failed login attempt the failed logon count 
      is incremented for user X.
     
     Without this fix (without the event set):
      After 3 successive failures a sleep delay is introduced starting
       at 3 seconds and extending to 10 seconds max. During each delay
       the user X row cache lock is held in exclusive mode preventing
       any concurrent logon attempt as user X (and preventing any
       other operation which would need the row cache lock for user X).
     
     With the fix (with the event set):
      There is no sleep delay.
     
     In either scenario the configured logon profile rules are still
     applied (eg: The profile option FAILED_LOGIN_ATTEMPTS is still 
     honoured and so if the account becomes locked due to exceeeding
     this FAILED_LOGIN_ATTEMPTS then further attempts to
     log in will then correctly fail immediately with no delay).
     
    Note: 
     One off fixes for this issue for 11.1.0.7 do not need an event set -
     interim patches for 11.1 disable the delay unconditionally.
     
    Work Around:
     Ensure the correct password is used - especially for connection 
     intensive logons
     
 
    Getting a Fix
     Use one of the "Fixed" versions listed above
     (for Patch Sets / bundles use the latest version available as
      contents are cumulative - the "Fixed" version listed above is
      the first version where the fix is included)
     or
     You can check for existing interim patches here: Patch:7715339
 
总结:
alter system set event="10949 TRACE NAME CONTEXT FOREVER:28401 trace name context forever, level 1"  scope=spfile;
 
这2个event 仍是在11g 中推荐设置的
后经过验证确实是属于11g 错误密码验证延时功能所导致
CopyRight © 2022 站长资源库 编程知识问答 zzzyk.com All Rights Reserved
部分文章来自网络,