本文主要是介绍ORACLE RAC反应卡顿时enq: SV - contention和latch: row cache objects的分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
某客户数据库系统使用ORACLE RAC 11G版本，两个节点。在上午8点钟之后，业务开始大量进行时，出现严重的卡顿问题；在工程师分析后，发现当时出现了很多异常等待数据，如典型的enq: SV - contention 、enq: TX - row lock contention、enq: SQ - contention、cursor: pin S wait on X、latch: row cache objects、enq: US - contention；如何穿透这些异常事件，快速找到数据库异常的根本原因，快速进行解决呢？
1、快速查看主机性能、负载和磁盘空间；然后查看实时的SESSION状态以及收集AWR进行分析
实时的SESSION状态：
SQL> select program,sql_id,event,FINAL_BLOCKING_INSTANCE,FINAL_BLOCKING_SESSION2 from gv$session where status='ACTIVE' and BLOCKING_SESSION is not null ;PROGRAM SQL_ID EVENT FINAL_BLOCKING_INSTANCE FINAL_BLOCKING_SESSION
------------------------- --------------- ------------------------------ ----------------------- ----------------------
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
w3wp.exe 3zk1may0smdy8 enq: SV - contention 2 4347
ghsf.exe 0qk8kh49vs5gq enq: TX - row lock contention 1 12709
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347
w3wp.exe bn46318t1a0h4 enq: SV - contention 2 4347查看AWR中的等待事件及时间
节点1：
节点2：
2、从基本信息来看，出现了很多异常等待数据，如典型的enq: SV - contention 、enq: TX - row lock contention、enq: SQ - contention、cursor: pin S wait on X、latch: row cache objects、enq: US - contention；实时的会话最多的是enq: SV - contention；查询AWR中的TOP SQL，也是执行获取序列值的SQL。序列相关的SQL执行速度和时间排在数据库的最前列，主要为：Select SEQ_XXXX.NextVal From Dual；分析：序列对应的配置为(主要指标，CACHE=20，ORDER=Y)，RAC环境下默认的20缓存及ORDER=Y属性会急剧序列的性能问题：
基于此分析，紧急将序列CACHE值改为200后，处于卡顿的进程在逐渐下降，但是前端业务还未完全恢复；
3、继续从AWR中分析，节点2的latch: row cache objects等待进入视野；参考MOS文档上RAC database hangs with enq: SQ - contention & latch: row cache objects & enq: US - contention (Doc ID 1484604.1)、Resolving Issues Where 'Row Cache Lock' Waits are Occurring (Doc ID 1476670.1)等文档，查看对应的data dictionary cache问题，可以直观发现问题点：
4、看起来问题比较清楚，大量回滚端请求，查看对应UNDO表空间使用率，可以发现UNDO表空间使用率高，查看UNDO段状态，大量在UNEEXPIRED状态；因此快速对UNDO表空间进行扩容，问题解决。
Tablespace_Name Size(GB) Status Used Extents US_SIZE(GB) Used R
--------------- --------- ---------- ------------ ----------- ------
UNDOTBS1 253.00 ACTIVE 421 .39 .15
UNDOTBS1 253.00 EXPIRED 112364 87.16 34.48
UNDOTBS1 253.00 UNEXPIRED 145372 106.47 42.12
UNDOTBS2 188.00 ACTIVE 473 .42 .22
UNDOTBS2 188.00 EXPIRED 50811 25.62 13.67
UNDOTBS2 188.00 UNEXPIRED 172751 107.72 57.45
这篇关于ORACLE RAC反应卡顿时enq: SV - contention和latch: row cache objects的分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
