watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=


Q          题目如下所示:

在Oracle中,密码延迟验证是什么?如何屏蔽?


     
A          答案如下所示:          



答案:从Oracle 11g开始,如果一个用户使用不正确的密码尝试登录数据库,那么随着登录失败次数的增加,每次登录验证前延迟等待的时间也会增加。

通过设置EVENTS 28401可以屏蔽密码延迟验证:

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

设置该事件后重启数据库即可。关于28401事件的解释如下所示:

[[email protected] ~]$ 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.

对于正常的系统,由于密码的更改,可能存在某些被遗漏的客户端,不断重复尝试使用错误密码登录数据库,从而引起数据库内部长时间的“library cache lock”或“row cache lock”的等待,这种情形非常常见。这种现象在Oracle 10.2和11.1中体现的等待事件为:“row cache lock”,而在Oracle 11.2中体现的等待事件为:“library cache lock”。

当出现这类问题时,非常典型的AWR报告呈现如下。首先在TOP 5中,可能会看到显著的library cache lock的等待,以下范例来自Oracle 11.2.0.3版本的真实情况:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

 

若数据库版本小于11.2,则在AWR中可能的情况如下所示:

 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=


在这类情况下,时间模型(Time Model Statistics)中会显示如下指标,其中,“connection management call elapsed time”占据了主要的DB Time,这个等待直接表明是在建立数据库连接时产生的:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

 

此外,在AWR中的Dictionary Cache Stats部分也可以看到很明显的等待。

此问题在MOS上相应的文档为:“High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1)”。此外,从Oracle 11g开始,开启了密码大小写验证,如果数据库是从Oracle 10g升级或迁移过来的,那么需要特别的注意这个变化,可以通过初始化参数SEC_CASE_SENSITIVE_LOGON来控制这个特性。