Oracle11g 密码延迟认证导致library cache lock的情况分析

在 Oracle 11g 中,为了提升安全性,Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是,如果用户输入了错误的密码尝试登录,那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击。

但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的 Library Cache Lock的等待,这种情形非常常见。

如果遇到这一类问题,可以通过Event 28401关闭这个特性,从而消除此类影响,以下命令将修改设置在参数文件中:

ALTER SYSTEM SET EVENT =

‘28401 TRACE NAME CONTEXT FOREVER, LEVEL 1‘ SCOPE = SPFILE;

出现这类问题非常典型的AWR报告呈现如下,首先在 TOP 5 中,你可能看到显著的 Library Cache Lock 的等待 ,如果用sql查等待时间,则username列为空,以下范例来自11.2.0.3.0版本的真实情况:

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

这类问题,在Oracle的11g中是常见和确定的,在MOS上可以找到相应的记录:High ‘library cache lock‘ Wait Time Due to Invalid Login Attempts(1309738.1)此外Oracle 11g开启了密码大小写验证,如果从Oracle 10g升级过来,需要特别的当心这个变化,通过初始化参数SEC_CASE_SENSITIVE_LOGON 可以来控制这个特性。

下面是一个案例:网上摘取下来别人的案例

1,问题来源

以前遇到了问题修改了用户名密码后,发现用新密码登录被hang住的情况,然后整个公司的oa系统彻底瘫痪了,详细状况见以前的记录。

最近学习了oracle11g的新特性密码延迟,才明白问题所在是由于密码延迟导致。

大概情况是:从oracle11g开始,如果用户输入了错误的密码登录,那么随着登录错误次数的增加,每次登录前等待验证的时间也会增加,本意上是为了保护数据库被恶意登录的时候消耗太多db资源导致数据库消耗过高导致数据库服务器出问题,但是这里也引发了问题,如果使用错误密码登录过多,则会影响该用户的正常登录,也就是说密码有验证延迟导致你输入正确的密码登录也需要等待很久。给使用人员的体验就是数据库hang住了(其实你使用其它用户操作数据库完全正常)

2,案例演示

Oracle版本是11g分支11.2.0.1.0:

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as [email protected]_VM128

SQL>


设置时间显示:

SQL> set time on;

07:41:57 SQL> conn timdba/timgood;

Connected.

07:42:48 SQL> conn timdba/t;#开始尝试错误密码登录

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

07:42:49 SQL> conn timdba/t; #第1次错误登录消耗时间1秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:42:51 SQL> conn timdba/t; # 第2次错误登录消耗时间2秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:42:52 SQL> conn timdba/t; # 第3次错误登录消耗时间1秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:42:54 SQL> conn timdba/t; # 第4次错误登录消耗时间2秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:42:57 SQL> conn timdba/t; #第5次错误登录消耗时间3秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:43:02 SQL> conn timdba/t; # 第6次错误登录消耗时间5秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:43:07 SQL> conn timdba/t; # 第7次错误登录消耗时间5秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:43:13 SQL> conn timdba/t; # 第8次错误登录消耗时间6秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:43:20 SQL> conn timdba/t;# 第9次错误登录消耗时间7秒

ERROR:

ORA-01017: invalid username/password; logon denied

07:43:28 SQL>

07:43:29 SQL> conn timdba/timgood;

Connected.

07:43:40 SQL>

大家可以看到第4次,第5次开始,错误登录验证时间越来越长了。基本每次都延迟多一秒,而后面即使输入了正确密码,也会延迟十几秒了。

而在测试过程中,一旦输入正确密码,验证成功过后,这个错误延时就会清0,从0开始重新计算数字了:


08:15:30 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:15:34 SQL> conn timdba/timgood;

Connected.

08:15:37 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

08:15:39 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:15:40 SQL>

大家进一步扩散下思维,这只是单个session做测试的,如果是线上环境的话,成千上万个会话过来,如果密码都错误了,一起延时的话,按照一个操作多延迟一秒来算,基本要延迟1000秒了,也就是半个小时你登录界面卡在哪里了,这样给客户的体验就是输入了正确密码,结果点击了登录按钮,就卡住了,死活不动弹了,服务器瘫痪了,也就意味着应用系统hang住了。

3,新特性是双刃剑

Oracle的任何一个新特性都能带来性能上的提升和安全上的进一步保证,但是毕竟oracle也只是一个软件software而已,是software就会有bug,甚至被别人利用攻击了。

oracle在11g发布后的几个小版本中,没有给出彻底屏幕密码延迟的方法,但是oracle有强大的其它辅助功能,可以通过设置event事件来处理掉。

4,通过设置Event屏幕密码延迟

这里一般通常设置28401就足够了,如果遇到其它特殊情况,也可以再设置一下,接下来通过设置EVENTS 28401来实现屏蔽密码延迟验证:

ALTER SYSTEM SET EVENT = ‘28401 TRACE NAMECONTEXT FOREVER, LEVEL 1‘ SCOPE = SPFILE;

alter system set event="10949 TRACENAME CONTEXT FOREVER:28401 trace name context forever, level 1" scope=spfile;


SQL> set time on;

08:56:22 SQL> ALTER SYSTEM SET EVENT = ‘28401 TRACE NAME CONTEXT FOREVER, LEVEL 1‘ SCOPE = SPFILE;

System altered.

08:56:27 SQL> create pfile from spfile;

File created.

08:56:29 SQL>

之后重启oracle数据库生效了。


08:56:44 SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

08:57:05 SQL> startup;

ORACLE instance started.

Total System Global Area 835104768 bytes

Fixed Size 2217952 bytes

Variable Size 545261600 bytes

Database Buffers 281018368 bytes

Redo Buffers 6606848 bytes

Database mounted.

Database opened.

08:57:46 SQL>

再次验证错误密码延迟验证,可以看到几乎没有任何延迟了:


08:58:28 SQL> conn timdba/timgood;

Connected.

08:58:33 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

08:58:37 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:38 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:39 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:39 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:40 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:41 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

08:58:42 SQL> conn timdba/t;

ERROR:

ORA-01017: invalid username/password; logon denied

 

原文地址:https://www.cnblogs.com/andy6/p/9288143.html

时间: 2024-10-30 05:20:02

Oracle11g 密码延迟认证导致library cache lock的情况分析的相关文章

Oracle 11g下重现library cache lock等待事件

从下面的例子中可以看到,在生产数据库中对象的重新编译会导致library cache lock,所以应该尽量避免在业务高峰期编译对象.如果是package或过程中存在复杂的依赖关系就极易导致library cache lock的出现,所以在应用开发的过程中,也应该注意这方面的问题. session1: SQL> select * from v$version; BANNER -------------------------------------------------------------

Library cache lock/pin详解

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对

外键约束列没建索引导致大量library cache pin/library cache lock

清空一个100多万行的大表的数据,发现一直执行了几个小时: delete B001.T_B11; 通过以下SQL进行跟踪,发现经常会出现library cache pin和library cache lock的等待,怀疑有大量的recursive sql在执行,于是对这个session做了10046: 发现有大量的如下SQL执行,每删除1行T_B11,都会执行下面2条SQL一次, PARSING IN CURSOR #3 len=93 dep=2 uid=0 oct=3 lid=0 tim=14

rac数据库默认sql tuning advisor,导致大量library cache lock

问题现象:客户反映周六周日固定十点钟,一个程序会特别慢(大概10分钟),平时1到2秒.查看当时的日志发现:DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j002_51847.trc:ORA-04021: timeout occurred while waiting to l

impdp时卡住,DW等待library cache lock

同事反映impdp时在SCHEMA_REPORT/TYPE/TYPE_SPEC步骤卡住,1个多小时后也没有响应, 查下v$session: select program,sid, event,blocking_session from gv$session  where program like '%DW%'; 结果为: DW01,98,library cache lock,213 DW03,13,library cache lock,213 DW02,36,library cache lock

library cache lock和cursor: pin S wait on X等待

1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: TOP 5 EVENT: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor

【翻译自mos文章】找到持有library cache lock session的方法

找到持有library cache lock session的方法 参考自: How to Find which Session is Holding a Particular Library Cache Lock (文档 ID 122793.1) 其实就是两种方法: 一.Systemstate Analysis 此处不做翻译,原文转载 Systemstate event will create a tracefile containing detailed information on eve

Library Cache: Lock, Pin and Load Lock

What is "Library cache lock" ? This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either: One client can prevent other clients from accessing the same object. The client can

共享池之六:shared pool latch/ library cache latch /lock pin 简介

latch:library cache --desc v$librarycache; latch:library cache用于保护hash bucket.library cache lock保护HANDLE.library cache pin保护library cache object--LCO.从10G开始,library cache lock和library cache pin被MUTEX部分取代.暂时不讨论MUTEX.latch:library cache的数量:[email prote