一次数据库响应慢分析

来源:这里教程网 时间:2026-03-03 16:38:18 作者:

问题详细描述

2014 年10月15号12点30分,CRM数据库一节点数据库响应极其慢,导致后台应用无法继续。登陆检查数据库,发现大量的enq: US – contention及enq: SQ – contention等待事件,导致数据库进程严重积压,会话响应缓慢。

为缓解系统压力,首先重建UNDO表空间以缓解enq: US – contention等待事件。在重建并替换完UNDO后,重启数据库,效果不明显,大量的回滚事务依旧存在,13点00分,在替换UNDO效果不明显的情况下,我们添加隐含参数:“_UNDO_AUTOTUNE“=FALSE关闭UNDO的自动调整特性。此时数据库响应正常,业务系统正常。后续我们对本次故障进行信息收集并分析故障原因。

 

重大事件支持细节

我们通过替换UNDO 添加隐含参数来解决enq: US – contention 这个关于UNDO的等待,后续分析并处理关于enq: SQ – contention的SEQUENCE等待。

时间点

故障处理关键点

10-15 12:30

CRM 一节点业务运行缓慢,数据库大量等待事件

10-15 12:40

排查并分析原因,替换UNDO表空间

10-15 12:50

添加隐含参数,禁用UNDO自动调整

10-15 13:00

对后续的问题进行收集并详细分析

10-15 14:20

写故障分析报告

 

数据库问题的现象如下:

1 、2014年10月15日12点30分,接联通电话,告知CRM核心数据库一节点实例异常导致数据库响应缓慢,业务运行异常。

2 、远程拨号检查数据库异常原因,分析数据库缓慢原因

检查数据库一节点等待事件:

       SID   EVENT                                      SQL_ID ----------   ---------------------------------------- -------------       1549   enq: SQ - contention       1570   enq: US - contention                       0jdpgs42gzwtt       1576   enq: US - contention                       3h05q2u88zup7       1590   enq: US - contention                       dwfnn4vz3k999       1591   enq: US - contention                       dwfnn4vz3k999       1592   enq: US - contention                       d0zwwfwy1ka03       1594   enq: SQ - contention       1598   enq: US - contention                       1mappfj3bf4ss       1609   enq: SQ - contention       1628   enq: SQ - contention       1637   enq: US - contention                       52skk1qhxmcf0          SID   EVENT                                      SQL_ID ----------   ---------------------------------------- -------------       1639   enq: SQ - contention       1646   enq: SQ - contention       1661   enq: US - contention                       2jgg7yzhnbqyn       1674   enq: US - contention                       f185h57q40zxz       1679   enq: US - contention                       6ffnkxws367vr       1681   enq: US - contention                       gsj20qadyguh1       1684   enq: US - contention                       fy0bjb6spurx4       1691   enq: US - contention                       dwfnn4vz3k999       1698   enq: SQ - contention       1702   enq: SQ - contention       1715   enq: TX - row lock contention              743bfk8w1qp7v          SID   EVENT                                      SQL_ID ----------   ---------------------------------------- -------------       1717   enq: US - contention                       cudgcw4fqy8zz       1730   enq: SQ - contention       1757   enq: US - contention                     af2j8jyb1zfzu       1760   enq: US - contention                       bcf9yan5h2m3c       1763   enq: SQ - contention       1769   enq: US - contention                       dwfnn4vz3k999       1770   enq: SQ - contention       1771   enq: US - contention                       70j4acnazq6c6       1773   enq: US - contention                       dwfnn4vz3k999       1775   enq: US - contention                       fy0bjb6spurx4

3 、以上等待事件大量的集中在enq: US – contention并且相关的SQL都不尽一致。

为缓解问题,首先添加并替换UNDO数据文件:

create undo tablespace UNDOTBS3 datafile   '+DATA/crmdb/datafile/undotbs03.dbf' size 4G autoextend on; alter tablespace UNDOTBS3 add datafile   '+DATA/crmdb/datafile/undotbs3_02.dbf' size 4G autoextend on; alter tablespace UNDOTBS3 add datafile   '+DATA/crmdb/datafile/undotbs3_03.dbf' size 4G autoextend on; alter tablespace UNDOTBS3 add datafile   '+DATA/crmdb/datafile/undotbs3_04.dbf' size 4G autoextend on;

 

4 、添加完后整体效果并不明显,进一步分析该问题,并确认ORACLE MOS文档:

How to correct performance issues with enq: US - contention related to undo segments (Doc ID 1332738.1)

根据文档给出的建议,我们进一步关闭了UNDO的自动调整新特性:

调整完后,检查发现该等待事件已经消失。进一步收集故障时间段的AWR等报告,并针对enq: SQ – contention等待事件进行分析

 

5 、根据enq: SQ – contention等待事件,我们检查最近一段时间数据库SEQUENCE的CACHE:

SQL> SELECT OWNER,OBJECT_NAME,CREATED FROM   DBA_OBJECTS WHERE OBJECT_TYPE='SEQUENCE' AND CREATED > SYSDATE-3;   OWNER       OBJECT_NAME                         CREATED --------- ---------------------------------   ------------------- ZJUCRM1O    SEQ_BMS_OTHERFEE_ID                 2014-10-14 12:55:16 ZJUCRM1O  SEQ_UCS_ACCT_RELA_ID              2014-10-14 16:07:51 ZJIOM       RES_EQPT_PROJECT_RES_INFO$SEQ       2014-10-14 21:24:00 ZJIOM       RES_EQPT_PROJECT_USER_INFO$SEQ      2014-10-14 21:24:06

  检查以上几个SEQUENCE对应的CACHE_SIZE大小:

SQL> SELECT SEQUENCE_OWNER,CACHE_SIZE FROM   DBA_SEQUENCES WHERE SEQUENCE_NAME='SEQ_UCS_ACCT_RELA_ID';   SEQUENCE_OWNER                 CACHE_SIZE ------------------------------ ---------- ZJUCRM1O                                 20 SQL> SELECT SEQUENCE_OWNER,CACHE_SIZE FROM   DBA_SEQUENCES WHERE SEQUENCE_NAME='SEQ_BMS_OTHERFEE_ID';   SEQUENCE_OWNER                 CACHE_SIZE ------------------------------ ---------- ZJUCRM1O                                 20 SQL> SELECT SEQUENCE_OWNER,CACHE_SIZE FROM   DBA_SEQUENCES WHERE SEQUENCE_NAME='RES_EQPT_PROJECT_USER_INFO$SEQ';   SEQUENCE_OWNER                 CACHE_SIZE ------------------------------ ---------- ZJIOM                                    20 SQL> SELECT SEQUENCE_OWNER,CACHE_SIZE FROM   DBA_SEQUENCES WHERE SEQUENCE_NAME='RES_EQPT_PROJECT_RES_INFO$SEQ';   SEQUENCE_OWNER                 CACHE_SIZE ------------------------------ ---------- ZJIOM                                    20      

以上SEQUENCE的CACHE都采用了默认的大小—即20,该值远远无法达到业务所需要的需求,建议调整以上序列的CACHE大小。

 

结论及解决方案

1. 检查业务系统用户的SEQUENCE的CACHE大小,对CACHE设置不足的SEQUENCE进行修改

2. 保持UNDO的自动调整设置,观察并后续考虑调整回来。

 

相关推荐