oracle数据库性能问题跟踪案例

oracle数据库性能问题跟踪案例

一． 现象

在打开工单时忽然发现较平时慢了非常多，打开工单界面，需要刷新将近2分钟才正常载入。网元视图也存在同样的情况。影响用户工单的处理。 数据库环境简单介绍：

1.RAC双机

2.数据库主机物理内存分别为16G 3.数据库主机CPU分别为16个

4.两节点均为ORACLE 10.2.0.4.0版本,ORACLE 的SGA设置为6G

二． 分析过程

2.1 传统方法，整体排查，空喜一场，暂无所获

根据该情况，做了11点到12点的AWR采样报表进行分析（默认是一小时一个采样），并没有发现特别异常的情况，查看数据库告警日志，也并没发现异常情况。接下来查看数据库监听日志情况，无意发现日志非常庞大，有1G左右，如此大的日志必然导致写入会比较缓慢，因此怀疑是监听日志太大导致前台连接缓慢。当即及时清理了日志，发现前台立即恢复了正常。当时以为问题解决了。结果在当天的晚上19点多又出现问题了。监听日志非常小，看来中午解决问题的方法是巧合，并没有真正解决问题。

继续做了19点到20点这时间段的AWR报表采样，看报表整体并不能发现数据库有啥问题。不解的是，过了20点，再问现场人员，居然系统又恢复了，现场人员告知工单系统使用非常正常，再也不卡了。

28日上午又接连出现工单操作很卡，过一会儿又恢复正常的情况，电信局方对此很不满。

2.2即时定位，精确打击，苦尽甘来，终获突破 2.2.1 问题再现时进行实施跟踪

看来AWR默认的一小时一次的采样太泛了，无法准确定位出问题，因为前台觉得工单处理缓慢的时间一般不长，大致10来分钟，但是却频频发生。看来方法应该改变了，应该采取工单处理缓慢时做AWR报表跟踪，这样才能突出重点。于是我要求现场人员遇到问题时立即电话通知我

在18点的时候，系统又出现这样的问题了，此时现场人员及时电话联系了我，当时安

排如下操作

步骤1．先登录数据库主机，sqlplus bosswg/bosswg登录后，执行如下：

exec dbms_workload_repository.create_snapshot();

步骤2.接下来，新疆前台人员操作前台界面（这个时候执行非常缓慢，需要2分钟才可以正常载入页面） 步骤3.

--2分钟后，执行如下：

exec dbms_workload_repository.create_snapshot(); 步骤4. 紧接着，执行如下跟踪@?/rdbms/admin/awrrpt.sql将开始和结束的这2分钟时间做一个短暂的AWR报表分析，看看系统主要等待事件

2.2.2 分析即时AWR报表查询出主要等待事件

观察AWR报表，我们可以看到，我们把时间范围缩短到非常精确的2分钟范围,具体如下

在这个精确的基础上再观察AWR报表,终于观察到了,原先一小时的采样不能突出重点, Top 5 Timed Events 排在第一位的是CPU time,而现在情况变化了,我们可以翡翠明显的观察到一个等待事件read by other session , 说明数据库存在读的竞争，根据文档，这个事件的解释如下：

This event occurs when a session requests a buffer that is currently being read into the buffer cache by another session. Prior to release 10.1, waits for this event were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event

AWR报表，具体如下:

2.2.3 根据AWR时段进一步分析ASH报表查找问题SQL

到底是什么语句导致数据库在前台工单刷新缓慢的时候出现这个严重的read by other session的等待事件呢？这个时候观看ASH报表是一个非常好的方法，ASH可以很方便的定位到主要等待事件和具体哪个SQL有关系，是一个不可多得到ORACLE好工具。观察结果如下：

我把SQL_ID=7v6brfxyyzxh7和buwbzrt3vkkfw的SQL语句发给新疆现场人员，并告知是这两个SQL导致了整个系统运行缓慢。结果新疆先擦好难过人员对此非常不解，答复是不可能，因为在前台操作工单的时候，根本没有运行这个语句，这个语句是告警监控类的，而前台他们操作的是工单扭转类。

面对现场人员的疑问，我心里更有数了，可以猜测到，正是由于前台在操作工单的时候，系统恰好在跑刚才我说的那两个语句，这个时候前台操作就慢了，而什么时候恢复正常呢？就是在这两个语句没有运行的时候。也正好解释了为什么工单查询会时快时慢。为了证明自己的观点消除现场人员的疑问，我建议他们现场做个实验（当时系统正好是正常状态），让他们操作一下前台的告警监控的菜单进行查询，并且多点开几个，然后再打开工单进行操作。结果很快现场人员反馈，工单操作非常卡，要2分多钟才可以打开，故障很快再现了。接下来，等告警监控的查询操作完全结束后，工单操作又开始飞快起来。

看来问题终于定位出来了，现在的问题就在于，告警类查询到底有啥问题，为什么会导致系统产生如此大的热点块竞争导致的事件read by other session

首先分析SQL_ID=7v6brfxyyzxh7的语句，该语句非常冗长，具体代码如下

select *

from (select rownum sid, a.*

from (select a.ne_alarm_list_id id, a.flow_id, /*流程ID*/

a.oprt_state oprtState, /*操作状态*/ a.alarm_state alarmState, /*告警状态*/ a.alarm_Level alarmLevel, /*告警级别*/ a.perf_msg_id, /*性能消息ID*/

a.alarm_class alarmClass, /*告警类别*/

to_char(a.generate_time, 'yyyy-mm-dd') generatedate, /*产生日期*/ to_char(a.last_generate_time, 'yyyy-mm-dd') lastdate, /*最后产生日期*/

b1.list_label alarm_type, c1.ne_name, d.kpi_name, a.kpi_value,

decode(c1.ne_flag, 6, e.region_name, c2.ne_name) datasource, '

decode(a.alarm_Level,1','red','2','orange','3','yellow','green') || ';\\\ decode(a.alarm_Level,'1','严重','2','重要','3','一般','未知') || '' alarm_Level, to_char(a.generate_time, 'yyyy-mm-dd hh24:mi:ss') generate_time,

to_char(a.last_generate_time, 'yyyy-mm-dd hh24:mi:ss') last_generate_time,a.alarm_times, decode(a.OPRT_STATE,'20', to_char(a.CONFIRM_TIME, 'yyyy-mm-dd hh24:mi:ss'), '25',

to_char(a.SUSPEND_TIME, 'yyyy-mm-dd hh24:mi:ss'),'30',to_char(a.CLEAR_TIME, 'yyyy-mm-dd hh24:mi:ss'),'40',to_char(a.DELETE_TIME, 'yyyy-mm-dd hh24:mi:ss')) executeTim,b2.list_label alarm_state,

DECODE(A.FLOW_ID, '', '未派单', '已派单') work_state /*自定义列项*/ from ne_alarm_list a, (select *

from TP_DOMAIN_LISTVALUES

where domain_code = 'DOMAIN_NE_ALARM_TYPE') b1, (sel ect * from tp_domain_listvalues where domain_code = 'DOMAIN_ALARM_STATE') b2, (select *

from tp_domain_listvalues

where domain_code = 'DOMAIN_DR_ID_FLAG') b3, (select *

from tp_domain_listvalues

where domain_code = 'DOMAIN_ALARM_OPRT_STATE') b4, net_element c1, net_element c2, kpi_code_list d, manage_region e, kpi_mapping_cfg f, ne_trans_alarm nta,

(SELECT T.PRIMARY_ID \ SUM(T.HAS_READ) \ FROM TREE_PRIVILEGE T WHERE T.TREE_CFG_NAME = :1

AND T.ASSIGN_OBJECT IN (:2, :3, :4, :5, :6, :7) GROUP BY T.PRIMARY_ID) \ where NVL(a.CONFIG_NE_ID, a.NE_ID) = \

AND NVL(\ and b1.list_value = a.alarm_Type and a.ne_id = c1.ne_id

本文来源：https://www.bwwdw.com/article/9tyv.html