进一步对上一篇客户的环境进行排查，发现同步程序是以短连接的形式访问数据库，平均每秒70次的连接；通过在测试环境进行批量短连接测试，重现大量

select /*+ connect_by_filtering index(sysauth$ i_sysauth1) */ privilege#, bitand(nvl(option$, 0), 8), grantee#, level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0

的问题。
（一）
测试环境，并接入EasyDB数据库管控软件

sys@ORCL> select * from v$version;BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Productionsys@ORCL> show parameter auditNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /u01/app/oracle/admin/orcl/adump
audit_sys_operations                 boolean     FALSE
audit_syslog_level                   string
audit_trail                          string      DBsys@ORCL> show parameter cursor_sharingNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing                       string      EXACT

（二）
简单编写shell脚本，发起大量数据库连接

#more /home/oracle/connect.sh for i in {1..200000}
dofor j in {1..40}do  sh /home/oracle/conn.shdone
done#more /home/oracle/conn.sh
#只执行简单的查询操作，之后退出sqlplus baiyang/oracle@orcl << EOFselect * from v\$version;exit;EOF#发起多个job执行，加大并发，执行将近一个小时 nohup sh connect.sh > /dev/null 2>&1&

（三）
查看EasyDB监控信息，这时各项指标飙升，但是TPS=0，
QPS，逻辑读明显上升

Oracle CPU、DBTime明显上升

主机CPU飙升

基本上是软解析，和客户环境遇到的不同

开了DB审计，引起log file sync 等待事件

（四）
分析listener.log 文件，确认每秒发起的连接数

grep '26-DEC-2018'  listener.log | sed 's/\*.*SERVICE_NAME=/  /g;s/).*HOST=/ /g;s/).*$//g'   | awk  '{if(NF==4){print "insert into t_tab  values('\''"$1"'\'','\''"$2"'\'','\''"$3"'\'','\''"$4"'\'');"}}'   > connect.txt
# 入库
@/u01/app/oracle/diag/tnslsnr/172-16-8-141/listener/trace/connect.txt
# 查询如下

可以看到这段时间监听每秒都响应了大量的连接请求
（五）
分析AWR报告，看看会有什么变化

因为开了SQL审核，所以有入库的操作；
最后一条是我们执行的测试SQL；
其他则都是递归SQL，大量的递归SQL；
但是不存在硬解析，这个客户环境的现象不一致

（6）
通过测试，重新了数据库问题，并验证在未执行 set role 时，同样会导致；
客户应用程序存在大量短连接，这会导致数据库、服务器资源飙升，并且会导致监听无法响应更多请求；
因客户的程序已经找不到开发商，目前很难对应用程序进行排查；
cursor_sharing=FORCE，虽然会带来一些优势，但官方不建议将此作为长久的优化方式；
提醒客户更新业务架构，使用长连接，并且自主掌握核心代码。