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

----------

28

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

TO_CHAR(28

----------

1c

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