AWR报告中Top 10 Foreground Events存在”reliable message”等待事件的处理办法

操作系统版本:HP-UNIX B.11.31

数据库版本:11.2.0.4 RAC

(一) 问题概要

(1)在AWR报告的Top 10 Foreground Events中发现reliable message占用了较高的DB Time,如下:

Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                               Total        Wait         % DB
Event                          Waits        Time Avg(ms) time   Wait Class
------------------------------ ------------ ---- ------- ------ ----------
reliable message               34,293,326   1430  42     64.1   Other
DB CPU                         265                       11.9
enq: TX - row lock contention  2,556,859    114K  45     5.1    Application
PX Deq: Signal ACK RSG         102,595      101K  985    4.5    Other
log file sync                  6,458,803    86.5  13     3.9    Commit
cursor: pin S wait on X        184,770      34.8  189    1.6    Concurrent

(2)result cache被使用

SQL> show parameter result_cache_max_size

NAME                                  TYPE         VALUE
------------------------------------  -----------  ------------------------------
result_cache_max_size                 big integer  5248K

(3)查询给gv$chanel_waits显示高等待的组件

SELECT CHANNEL, SUM(WAIT_COUNT) SUM_WAIT_COUNT
  FROM GV$CHANNEL_WAITS
 GROUP BY CHANNEL
 ORDER BY SUM(WAIT_COUNT) DESC;

CHANNEL                                                 Wait Count
------------------------------------------------------  --------------
Result Cache: Channel                                   307718423
kxfp control signal channel                             97080
RBR Channel                                             60807
MMON remote action broadcast channel                    28256
obj broadcast Channel                                   14736
kill job broadcast - broadcast channel                  367
parameters to cluster db instances - broadcast channel  15
Broker IQ Result                                        5
service operations - broadcast channel                  4
quiesce Channel                                         2

(二)原因

如果满足上面的3个条件,那么可以确定该等待事件由result cache处理相关的bug_19557279造成,该问题在Oracle 12.2版本中修复。

(三)解决方案

在11G中如何解决,Oracle提供了3种方案:

1.更新数据库版本到12cR2;

2.应用补丁18416368;

3.禁用结果缓存,需要重启数据库实例生效

SQL> alter system set result_cache_max_size=0;

参考文档:MOS上文档ID :1951729.1

【完】

原文地址:https://www.cnblogs.com/lijiaman/p/10520110.html

时间: 2024-11-05 22:40:41

AWR报告中Top 10 Foreground Events存在”reliable message”等待事件的处理办法的相关文章

关于AWR报告中几个命中率指标的初步解释(转)

文章转自:http://blog.itpub.net/24558279/viewspace-762371/ 从Oracle 10g开始,Oracle给广大DBA提供了一个性能优化的利器,那便是Automatic Workload Repository性能报告. 在拿到一份AWR性能报告后,通过分析AWR报告来定位数据库性能问题时,在AWR报告的报告头中,我们会看到类似如下的一些命中率指标: 那么,这些关于Oracle内存的几个关键指标以及Instance效率的几个指标又该如何理解呢? 1 这几个

【翻译自mos文章】在12c中Create or Truncate Table时非常慢,等待事件为 DFS Lock Handle wait

来源于: Create or Truncate Table Slow in 12c While Waiting for DFS Lock Handle wait (文档 ID 2085308.1) APPLIES TO: Oracle Database - Enterprise Edition - Version 12.1.0.2 and later Information in this document applies to any platform. SYMPTOMS In 12c dat

(转载)Oracle AWR报告指标全解析

Oracle AWR报告指标全解析 2014-10-16 14:48:04 分类: Oracle [性能调优]Oracle AWR报告指标全解析 2013/08/31 BY MACLEAN LIU 26条评论 [性能调优]Oracle AWR报告指标全解析 开Oracle调优鹰眼,深入理解AWR性能报告:http://www.askmaclean.com/archives/awr-hawk-eyes-training.html 开Oracle调优鹰眼,深入理解AWR性能报告 第二讲: http:

[转]oracle awr报告生成和分析

转自:http://blog.csdn.net/cuker919/article/details/8767328 最近由于数据库cpu占用非常高,导致VCS常常自动切换,引起很多问题. 最近学习一下数据库awr分析数据库sql执行性能的分析报告.下面将初步讲解一下: 1.先登陆数据库,生成awr报告. linux:~ # su - oracle[email protected]:~> sqlplus '/as sysdba' SQL*Plus: Release 11.1.0.6.0 - Prod

Oracle的AWR报告分析

* 定义:awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告. 如何分析: * 在看awr报告的时候,我们并不需要知道所有性能指标的含义,就可以判断出问题的所在,这些性能指标其实代表了oracle内部实现,对oracle理解的越深,在看awr报告的时候,对数据库性能的判断也会越准确 * 在看性能指标的时候,心里先要明白,数据库出现性能问题,一般都在三个地方,

awr报告基础

awr报告基础 study oracle基础 awr 1. awr是什么 awr是oracle 10g后提供的一种性能收集和分析工具,它能够提供一个时间段内整个系统资源使用情况的报告. 2. awr生成方式 修改awr生成时间,保存周期 -- interval 快照间隔,单位是分钟 -- retention 快照保留周期,单位是分钟 execdbms_workload_repository.modify_snapshot_settings(interval=>60,retention=>7*2

使用AWR报告来诊断数据库性能问题

对于数据库整体的性能问题,AWR的报告是一个非常有用的诊断工具. 一般来说,当检测到性能问题时,我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长,那么AWR报告就不能很好的反映出问题所在. 还应该收集一份没有性能问题的时间段的AWR报告,作为一个参照物来对比有问题的时间段的AWR报告.这两个AWR报告的时间段应该是一致的,比如都是半个小时的,或者都是一个小时的. 关于如何收集AWR报告,请参照如下文档: Document 1363422.1

一份11gR2 rac awr报告的简单分析

昨晚网友发来一份awr报告,希望帮忙分析一下.由于其他信息都没有,仅仅只有一份awr,鉴于目前有大多的朋友还不太熟悉或者说不知道如何去进行awr的分析.我这里就拿这个awr来进行分析,当抛砖引玉了.首先申请,网上分析awr的文章不少,大家也都可以参考一下. 首先来看awr前面部分信息,了解下系统的版本,以及大概判断下系统负载如何. 从上面信息我们可以得出如下结论:—-数据库是一套11.2.0.2的RAC—-Solaris 64bit环境,48c—-每个cpu 的可用处理时间是3591.6 s,

借助AWR报告分析解决oracleCPU过高的问题(转)

原文地址:http://www.cnblogs.com/crystal-guoguo/p/4213458.html 简介:在oracle数据库中,有两个非常实用的自带监控工具EM(Enterprise Manager)和AWR(Automatic Workload Repository).其中,通过AWR报告可以生成易于阅读的监控报告,可协助进行性能问题的诊断和分析.本期将介绍一些AWR报告的基本使用和在性能问题诊断中的应用. 什么是AWR:      从oracle 10g开始,使用名为GAT