11G 修改用户密码导致的row cache lock

最新推荐文章于 2021-04-06 17:49:43 发布

cotchte0421

最新推荐文章于 2021-04-06 17:49:43 发布

阅读量196

点赞数

文章标签：数据库

11g客户端在进行建立连接的时候，如果密码连续错误两次的话，会导致下一次连接的时候，增加验证时间，每错一次，验证时间累加一次。一旦连接成功（任何一个客户端，不一定非要是当前客户端），验证时间就会被清零。

我们测试库遭遇的修改密码导致的row cache lock非常可能是因为这个特性。

我没有找到ORACLE的官方文档介绍这个特性。只在Oracle Database 11g: New Features for DBAs and Developers介绍新特性的书里提到了这个特性。

英文里的这个特性叫做：delayed failed logins

实验会出现类似如下的情况：

eve@CRMP>conn eve/cc

ERROR:

ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:00.70

eve@CRMP>conn eve/cc

ERROR:

ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:00.70

eve@CRMP>conn eve/cc ------------------------------第三次开始时间开始增加

ERROR:

ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:02.70

eve@CRMP>conn eve/cc

ERROR:

ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:03.96

eve@CRMP>conn eve/cc

ERROR:

ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:05.96

ORACLE在进行验证期间，会以X模式持有eve用户所在row cache区域对象。因此如果在验证期间有其他会话以此用户登录，会导致

都被hang住，等待事件是row cache lock。因为这些会话在尝试登录期间要以s或x模式来获得这个row cache lock，至于到底是x还是s模式，我不知道，没有去验证，但是无论是哪种，都跟X模式是不兼容的，肯定会被hang住。

可以在被hang住期间dump 出row cache 区域来观察锁模式。

BUCKET 2821:

row cache parent object: address=0xee6bfa38 cid=7(dc_users)

hash=ab6477fb typ=11 transaction=0xfddb2e78 flags=00000002

wn=0xee6bfb00[0xece99908,0xece99908] wat=0xee6bfb10[0xe9bac0c0,0xea59bf50] mode=X----------以X模式持有eve对象上面的row cache lock.

status=VALID/-/-/-/-/-/-/-/-

set=0, complete=FALSE

set=1, complete=FALSE

set=2, complete=FALSE

data=

0000001c 56450003 00000045 00000000 00000000 00000000 00000000 00000000

00000000 45380010 44364241 31443536 42444344 00004131 00000000 00000000

00000000 45440016 4c554146 4f435f54 4d55534e 475f5245 50554f52 00000000

00000000 00000006 00000003 00000000 01010000 04056e78 00232916 00000000

00000000 00000000 00000000 0000000c 00000000 3a53003e 46363241 34323833

39394139 30353135 31303534 41353141 31304446 33324539 33454535 38384534

38434238 36324230 33394439 46424533 34434646 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 ab6477fb

ee6bfa38 00000000 f8dbe020 00000000 f8dbe020 00000000 00000001 cb380b04

ee6bfa38 00000000 f8d510b0 00000000 f8d510b0 00000000 00000002 00000000

ee6bfa38 00000000 ee6bfd38 00000000 ee6bfd38 00000000

因此11G以后修改密码也需要注意，一定要确认应用端的密码都是正确的。

一般应用端都有密码重试机制，即使在密码错误的情况下，也会以一定的间隔时间，不停的重试。

这种重试在11G会造成严重的问题。

根据如下方法跟踪此问题的row cache lock：

eve@CRMP>select USER_ID from dba_users where USERNAME='EVE';

USER_ID

----------

eve@CRMP>select to_char(28,'xxxx') from dual;

TO_CHAR(28

----------

alter session set events 'immediate trace name row_cache level 12';

在dump文件里搜索0000001c，它会是DATA区域的第一个值。

time echo "select sysdate from dual;" | sqlplus -s vodka/ss
ERROR:
ORA-01017: invalid username/password; logon denied