bug 7715339 登录失败触发 ‘row cache lock’ 等待

Bug 7715339 - Logon failures causes "row cache lock" waits - Allow disable of logon delay

(文档 ID 7715339.8) 到底部

修改时间:2012-7-26类型:PATCH

为此文档评级 通过电子邮件发送此文档的链接 在新窗口中打开文档 可打印页

Bug 7715339  Logon failures causes "row cache lock" waits - Allow disable of logon delay

This note gives a brief overview of bug 7715339.

The content was last updated on: 19-JUN-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 >= 11.1

Versions confirmed as being affected

11.1.0.7

Platforms affected  Generic (all / most platforms affected)

Fixed:

This issue is fixed in

11.2.0.1 (Base Release)

Symptoms:

Related To:

Performance Affected (General)

Waits for "row cache lock"

Security ( Authentication / Privileges / Auditing )

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

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:7715339 (This link will only work for PUBLISHED bugs)

Note:245840.1 Information on the sections in this article

bug 7715339 登录失败触发 ‘row cache lock’ 等待

时间: 2024-08-16 01:22:08

bug 7715339 登录失败触发 ‘row cache lock’ 等待的相关文章

oracle row cache lock 之sequence

今天遇到一个生产库产生大量row cache lock,以下是相应步骤: 1 查询当时P1的情况 select INSTANCE_NUMBER,p1,count(*) cnt from dba_hist_active_sess_history where event='row cache lock' and SAMPLE_TIME>=to_date('2018-08-31 10:00:00','yyyy-mm-dd hh24:mi:ss') and SAMPLE_TIME <=to_date(

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 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

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

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

在 Oracle 11g 中,为了提升安全性,Oracle 引入了『密码延迟验证』的新特性.这个特性的作用是,如果用户输入了错误的密码尝试登录,那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击. 但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的 Library Cache Lock的等待,这种情形非常常见. 如果遇到这一类问题,可以通过Event 28401关闭这个特性,从而消除此类影响,以

springmvc集成shiro登录失败处理

一般的登录流程会有:用户名不存在,密码错误,验证码错误等.. 在集成shiro后,应用程序的外部访问权限以及访问控制交给了shiro来管理. shiro提供了两个主要功能:认证(Authentication)和授权(Authorization);认证的作用是证明自身可以访问,一般是用户名加密码,授权的作用是谁可以访问哪些资源,通过开发者自己的用户角色权限系统来控制. shiro的会话管理和缓存管理不在本文范围内. 下面通过登录失败的处理流程来介绍springmvc与shiro的集成. 项目依赖:

登录窗体登录失败但是MainForm依然弹出无法结束的解决方法

问题描述:登录窗体登录失败但是MainForm依然弹出无法结束的解决方法 解决方法:把form3.close,exit; 改为application.terminate 结束退出程序: 参考链接:http://www.delphitop.com/html/chengxu/131.html delphi关闭程序Close,application.Terminate与halt区别 当Close是一个主窗体时,程序会退出.Close会发生FormClose事件,FormCloseQuery事件Halt

530 This FTP server is anonymous only vsftp服务器登录失败解决方案

http://blog.csdn.net/pipisorry/article/details/39647931 用本机用户登录vsftp出现错误: [email protected]:~#ftp ftp> open 127.0.0.1 Connected to 127.0.0.1. 220 (vsFTPd 2.3.5) Name (127.0.0.1:pipi): 530 This FTP server is anonymous only. Login failed. ftp> quit 登录