Oracle 数据库异常处理之latch: row cache objects

文章目录

问题描述

同事反馈有一个Oracle项目需要提供支援。根据描述11月13日起，数据库在9:00 - 11:00会有严重的性能问题，性能报告参考如下：
在这里插入图片描述
Top 5信息如下：

问题分析

从收到上述信息时，我大致感觉与之前遇到的Case雷同。此数据库版本是11.2.0.4版本，且没有任何补丁。

[Nov 25, 2020 12:48:05 PM]   OPatch invoked as follows: 'lsinventory '
[Nov 25, 2020 12:48:05 PM]   OUI-67077:
                             Oracle Home       : D:\APL\oracle\product\11.2.0\dbhome_2
                             Central Inventory : C:\Program Files\Oracle\Inventory
                                from           : n/a
                             OPatch version    : 11.2.0.3.4
                             OUI version       : 11.2.0.4.0
                             OUI location      : D:\APL\oracle\product\11.2.0\dbhome_2\oui
                             Log file location : D:\APL\oracle\product\11.2.0\dbhome_2\cfgtoollogs\opatch\opatch2020-11-25_12-48-04PM_1.log
[Nov 25, 2020 12:48:05 PM]   Patch history file: D:\APL\oracle\product\11.2.0\dbhome_2\cfgtoollogs\opatch\opatch_history.txt
[Nov 25, 2020 12:48:05 PM]   Starting LsInventorySession at Wed Nov 25 12:48:05 CST 2020
[Nov 25, 2020 12:48:06 PM]   Lsinventory Output file location : D:\APL\oracle\product\11.2.0\dbhome_2\cfgtoollogs\opatch\lsinv\lsinventory2020-11-25_12-48-04PM.txt
[Nov 25, 2020 12:48:06 PM]   --------------------------------------------------------------------------------
[Nov 25, 2020 12:48:06 PM]   Installed Top-level Products (1):
[Nov 25, 2020 12:48:06 PM]   Oracle Database 11g                                                  11.2.0.4.0
[Nov 25, 2020 12:48:06 PM]   There are 1 products installed in this Oracle Home.
[Nov 25, 2020 12:48:06 PM]   There are no Interim patches installed in this Oracle Home.
[Nov 25, 2020 12:48:06 PM]   --------------------------------------------------------------------------------
[Nov 25, 2020 12:48:06 PM]   Finishing LsInventorySession at Wed Nov 25 12:48:06 CST 2020

从STATSPACK可以获取到主要问题在于[latch: row cache objects]，通过分析日志发现dc_users与dc_tablespaces都处于比较高的水平。
在这里插入图片描述

DC_USERS
– This may occur if a session issues a GRANT to a user, and that user is in the process of logging on to the database.
– Excessive calls to dc_users can be a symptom of “set role XXXX”
– You can check the presents of massive login attempts, even the failed ones by analyzing listener.log (use OEM 12c-> All Metrics or by checking database AUDIT if available or using own tools).
– Bug 7715339 – Logon failures causes “row cache lock” waits – Allow disable of logon delay

DC_TABLESPACES
Probably the most likely cause is the allocation of new extents. If extent sizes are set low then the application may constantly be requesting new extents and causing contention. Do you have objects with small extent sizes that are rapidly growing? (You may be able to spot these by looking for objects with large numbers of extents). Check the trace for insert/update activity, check the objects inserted into for number of extents.

本来还想让收集一下进一步的信息进行分析

# 查询latch: row cache objects事件相关SQL语句
SELECT A.SQL_ID, COUNT(1)
  FROM V$ACTIVE_SESSION_HISTORY A, V$EVENT_NAME B
 WHERE A.SAMPLE_TIME BETWEEN
       TO_DATE('2020-11-14 09:00:00', 'YYYY-MM-DD HH24:MI:SS') AND
       TO_DATE('2020-11-14 11:00:00', 'YYYY-MM-DD HH24:MI:SS')
   AND A.EVENT_ID = B.EVENT_ID
   AND B.NAME = 'latch: row cache objects'
 GROUP BY A.SQL_ID
 ORDER BY 2 DESC;

# 查询SQL语句的执行计划，查看是否都与hash join有关系
SELECT * FROM TABLE(dbms_xplan.display_cursor('<SQL_ID>', NULL, 'advanced'));

问题解决

以往遇到的案例参考如下方式解决：
Slow Performance with High Waits for ‘row cache lock’ With Possible Database Hang (Doc ID 2189126.1)
Bug 13902396 - Hash joins cause “row cache objects” latch gets and “shared pool” latch gets (disabled fix) (Doc ID 13902396.8)

在Linux平台，可以先打13902396补丁，再设置如下Event：

 SELECT
    name,
    decode (bitmapped, 0, least (DFLincr, dflinit), bitmapped) -1 "Level"
FROM
    ts$;

event='45053 trace name context forever, level 127'

本次的环境是Windows，好像没有这个补丁。可能要将环境升级到Oracle 12c或以上才可以解决此问题。