密码错误登录导致大量Library Cache Lock等待事件案例

密码错误登录导致大量Library Cache Lock等待事件案例

一、案例背景

某项目RAC集群，负载很高，各业务系统执行很慢，以及客户端plsql连接数据库也有hang住迹象，已接近奔溃边缘，数据库版本：12.1.0.1.0。

二、排查过程

2.1 AWR/ASH

直接贴AWR




ASH

根据报告，awr负载很高，dm time在15000以上，并且有大量library cache lock等待事件，占了99.2%的DB TIME，同时在time model中的connection management call elapsed time时间占比与library cache lock接近。

connection management call elapsed time在oracle doc中的解释
https://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_3015.htm#r1c1-t18

Amount of elapsed time spent performing session connect and disconnect calls.

doc的解释为数据库在连接与断开连接消耗的时间。
从以上AWR以及ASH可以看出，很明显数据库的db time花在了不该花的地方。那么做个trace吧

2.2 SSD+hang trace

来个常规跟踪SSD(system state dump)+hang analyze

oradebug setorapname reco
oradebug unlimit
oradebug -g all hanganalyze 3
--等一分钟后再次执行hanganalyze分析
oradebug -g all hanganalyze 3
oradebug -g all dump systemstate 266
oradebug -g all dump systemstate 266
oradebug tracefile_name;

分析trace



看点1:
从上面的SSD trace也可以发现大量“library cache lock”，需要注意的是current sql那行以及如下的几行并没有具体的sql语句

看点2:
library cache lock等待事件有三个参数p1:handle address对象地址,p2:lock address 锁地址。p3:Mode+namespace申请锁的级别
2 - Share mode
3 - Exclusive mode

可以看出来上面trace中的p3参数由两部分组成
” p3: ‘100*mode+namespace’=0x4f0003“
mode=3
namespace=4f
p3为16进制，将其转换为10进制
HEX: 4f =>DEC: 79

然后再查x$kglob oracle核心视图,得出library cache中等待的是与账号登录有关

SQL> select distinct KGLHDNSP,KGLHDNSD from x$kglob where KGLHDNSP=79；
KGLHDNSP KGLHDNSD
---------- ------
79 ACCOUNT_STATUS

看点3：
其余trace还有大量相同的等待事件“library cache lock”

继续往下走,根据p1参数handle address往下搜


经过查看发现等待的对象ObjectName: Name=JXGGZYDB.107 Namespace=ACCOUNT_STATUS(79)，其中namespace与之前x$kglob查出的一致。

继续看
使用x$视图尝试查找阻塞会话

select sid,saddr from v$session where event= 'library cache lock';

select kgllkhdl Handle,kgllkreq Request, kglnaobj Object
from x$kgllk where kgllkses = '000000017F330970'
and kgllkreq > 0;

根据saddr查找请求会话（被阻塞）的对象信息object，object为sql执行语句的前80个字符，然而此案例查询结果居然为一个数字id

继续往下看，library cache lock被阻塞的会话都是“107”

经过查证x$kgllk的object为107的正好对应trace中”ObjectName: Name=JXGGZYDB.107 “，与dba_users的user_id一列值相同，也就是说被阻塞的对象仅仅是oracle用户名仅此而已。

看到这里已经有念头是否是应用端，数据库连接字符串密码配置错误，随即查看审计视图

select sessionid, userid, userhost, comment$text, spare1,cast (/* TIMESTAMP */(from_tz(ntimestamp#,'00:00') at local) as date)
  from aud$ where returncode = 1017  and ntimestamp# > sysdate - 10;

不过很可惜，项目上查询审计视图并无任何结果，无法从审计得知密码错误登录的ip。

继续往下看监听
抓取两个节点的监听日志文件，按照ip分组，查看具体时间段监听中ip建立的次数。
这里需要说明一点oracle的监听程序，只要客户端连接字符串ip、端口、服务名正常，在监听日志中都会establish，无论密码正确与否，已通过本地实验证实。

我们需要做的是把监听日志筛选出来，在数据库中进行查询
1、提取当日日志

grep '09-MAY-2019'  listener1.log | sed 's/\*.*SERVICE_NAME=/  /g;s/).*HOST=/ /g;s/).*$//g'   | awk  '{if(NF==4){print "insert into lislog2  values('\''"$1"'\'','\''"$2"'\'','\''"$3"'\'','\''"$4"'\'');"}}'   > lislog.sql

2、创建表并插入监听记录

 create table lislog(year varchar2(15),time varchar2(15),service varchar2(20),ip varchar2(20));

 @/DBSoft/grid/diag/tnslsnr/GGZYDB02/listener/trace/lislog.sql

3、提交

commit;

节点1：

SQL> select ip,count(*) from lislog2 where year='09-MAY-2019' group by ip order by count(*) desc;

IP                     COUNT(*)
-------------------- ----------
10.4.25.51                 8077
10.4.25.45                 3825
10.2.66.22                 3585
10.2.66.30                 3542
10.2.66.20                 2230
10.4.25.65                  151
10.4.25.11                  144
10.4.25.14                  136

节点2：

SQL> select ip,count(*) from lislog where year='09-MAY-2019' group by ip order by count(*) desc;

IP                     COUNT(*)
-------------------- ----------
10.4.25.51                 5601
10.4.25.45                 2038
10.2.66.22                 2018
10.2.66.30                 1848
10.2.66.20                 1705
10.4.25.65                  189
10.4.25.15                  134
10.4.25.14                  123
10.4.25.17                  121

很明显TOP 5的ip需要关注下，经过询问项目组，排名第一和第三的两个ip地址，当前已不再用于业务使用，并且这两个ip对应的数据库密码还是”过时“密码。

三、处理方式

根据监听日志排查出的结果，让项目组检查连接字符串数据库密码，更改正确密码之后，集群负载已大幅下降，可见如下业务高峰期（早上9点到12点）并且业务用户在plsq登录数据库已秒开，此前在登录时会有较长时间的hang。
修正密码前数据库负载：

修正密码后数据库负载：

四、总结

1、此次案例可以看出业务程序在使用不正确的密码之后，在业务繁忙时间段会产生大量"library cache lock"等待时间，给数据库负载产生极大的压力。
2、另外排查过程中有个可疑点至今还无法得到解释。此数据库aud$没有错误登录的记录，并且最新的审计记录也只有到2017年年底为止。（审计级别为db、表空间查询正常）
3、查阅资料后发现可以通过触发器将失败登录的会话信息插入到告警日志。
4、本地经过测试，发现在11g环境中同样可以复现library cache lock事件，详见我另外一篇测试的博客https://blog.csdn.net/kiral07/article/details/90166909

五、参考

1、Library Cache 诊断：Lock, Pin 以及 Load Lock (文档 ID 1548524.1)
2、How to Find which Session is Holding a Particular Library Cache Lock (文档 ID 122793.1)
3、几种常见的library cache lock产生的原因
https://blogs.oracle.com/database4cn/library-cache-lock
4、Oracle 应用短连接导致连接风暴
https://yq.aliyun.com/articles/682417

AWR
https://pan.baidu.com/s/1KS3rHM1li8k5uBKf5fCivg