数据库短连接风暴触发oracle bug 32164034

环境背景:

linux 7.5 oracle 19.8 rac

问题现象：

业务反馈，凌晨业务数据写入慢

问题分析：

1.看看凌晨期间，有什么特别的事务

AWR报告显示：

1. 期间每秒连接数较高
2. 硬解析很高
3. 存在row cache mutex等待事件
4. row cache mutex事件p1=10 p2=19

2.从数据库查看row cache mutex信息

3.mos查知识库

High “row Cache Mutex” Waits (Doc ID 2735198.1)

CAUSE
Dictionary Cache Stats shows high gets on a cache such as dc_users
Cache Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage
**dc_users ** 157,598,547 0.00 0 0 252 <<<<<<<<<<<<<<<<<<<<<<<<
dc_users 与库中查看v$rowcache 相对应。

Bug 30623138 - High row cache mutex wait on looking up dc_users (Doc ID 30623138.8)

Description
High waits on “row cache mutex” when looking up user or role information in user row cache (dc_users).
REDISCOVERY INFORMATION:
If there are lots of requests for mutex on user$ row cache, this bug could have been hit.

当rowcache为dc_users时，是有大量请求表user$。

SOLUTION
Recommend to apply patch 31933451.
It contains enhancement fix to reduce waits on ROW CACHE MUTEX.

Bug 32164034 - Database Hang Updating USER$ When LSLT (LAST SUCCESSFUL LOGIN TIME) Is Enabled (Doc ID 32164034.8)

Description
Database hung and application users not able to login to database.

Below query is blocking so many sessions:

update user$ set spare6=DECODE(to_char(:2, ‘YYYY-MM-DD’), ‘0000-00-00’, to_date(NULL), :2) where user#=:1

To Avoid this issue we need to apply the patch 32164034. With this patch we can disable the LSLT feature at PDB level
(making the setting effective to individual PDBs).

Note: This fix has been superseded by the fix in bug 33121934. For interim patches please use that fix instead of this one to address both issue

Bug 33121934 - Library cache lock / load lock / mutex x during connection storm (Doc ID 33121934.8)

Description
Concurrent logons for user may be affected due to Last Successful Logon Time (LSLT) update

REDISCOVERY INFORMATION:
If the concurrent logons for a user may be slow when the system is under heavy load and/or logon storm happens, all waiting for the Last Successful
Logon Time (LSLT) update to happen, this bug may have been rediscovered.

During a connection storm you may see wait events like:

• library cache: mutex X
• library cache load lock
• library cache lock
• gc buffer busy acquire

The fix introduces the parameter _disable_last_successful_login_time.

Two hidden system parameters have been added to optimize LSLT writes in
high load scenarios.

 _disable_last_successful_login_time_unlimited_iat - This controls whether users associated with a password profile with UNLIMITED Inactive Account Time will not have their LSLT updated. 

 _granularity_last_successful_login_time - This controls the granularity
 of LSLT update for _ALL_ users. Say, it is set to 30 seconds and then all
 users logons within that period of 30 seconds will NOT update the LSLT
 for that user.
复制

4.查看监听日志，分析是否存在大量连接数据库的请求

结果：确实存在大量的连接请求

解决办法

1.数据库打补丁，同时开启隐含参数规避更新表user$登陆时间字段

补丁：
p33121934_198000DBRU_Linux-x86-64.zip
隐含参数：
alter system set “_disable_last_successful_login_time”=true scope=spfile;

2.应用改变连接数据库方式

连接池的作用：

连接池是将已经创建好的连接保存在池中，当有请求来时，直接使用已经创建好的连接对数据库进行访问。这样省略了创建连接和销毁连接的过程。这样性能上得到了提高。

基本原理：

（1）建立数据库连接池对象（服务器启动）。
（2）按照事先指定的参数创建初始数量的数据库连接（即：空闲连接数）。
（3）对于一个数据库访问请求，直接从连接池中得到一个连接。如果数据库连接池对象中没有空闲的连接，且连接数没有达到最大（即：最大活跃连接数），创建一个新的数据库连接。
（4）存取数据库。
（5）关闭数据库，释放所有数据库连接（此时的关闭数据库连接，并非真正关闭，而是将其放入空闲队列中。如实际空闲连接数大于初始空闲连接数则释放连接）。
（6）释放数据库连接池对象（服务器停止、维护期间，释放数据库连接池对象，并释放所有连接）。

连接池的优点

连接池一般比直接连接更有优越性,因为它提高了性能的同时还保存了宝贵的资源。在整个应用程序的使用过程,当中重复的打开直接连接将导致性能的下降。而池连接只在服务器启动时打开一次，从而消除了这种性能问题。
   连接池主要考虑的是性能，每次获取连接和释放连接都有很大的工作量，会对性能有很大影响；而对资源来说起的是反作用，因为保存一定数量的连接是要消耗内存的。应用程序每次从池里获得Connection对象，而不是直接从数据里获得，这样不占用服务器的内存资源。所以一般要建立连接池，而连接的数量要适当，不能太大，太大会过多消耗资源。(所以，考虑2个方面，一个是内存，另一个是资源)。