暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

AWR报告分析之二:ges inquiry response 过高

原创 eygle 2012-11-23
1496

在一个朋友AWR报告中,ges inquiry response事件过高引起了忧虑。这个等待事件来自RAC集群,这里的GES指Global Enqueue Service,inquiry意思是查询确认,这个等待事件的意思可以从字面猜测出来,也就是GES等待查询确认。以下是这个等待事件的解释,主要是说这个等待和快速重配置时的Remaster资源重放有关。



Wait Event: "ges inquiry response"


Definition: The problem is related to fast rcfg where resource was only replayed on remastered resources.
The resource cleanup will only clean up the state (including inquiry state) on remastered resources and caused discrepancies in inquires state for non-remastered resources.



这个报告的主要等待如下:














































EventWaitsTime(s)Avg wait (ms)% DB timeWait Class
DB CPU 18,228 43.17 
ges inquiry response49,384,77113,890032.89Other
transaction5,3145,317100112.59Other
SQL*Net message from dblink1,271,6671,36513.23Network
PX Nsq: PQ load info query5,7731,1351972.69Other

但是实际上,这个报告的时间跨度过大(跨度为14小时),这里的等待可能不足以说明问题,以下数据显示服务器主机非常强劲,有160 CPUs和500G内存:














Host NamePlatformCPUsCoresSocketsMemory (GB)
SDSLDB1Linux x86 64-bit160808504.72


































Snap IdSnap TimeSessionsCursors/Session
Begin Snap:14322-Nov-12 09:00:30901.5
End Snap:15722-Nov-12 23:00:4473.7
Elapsed: 840.23 (mins)  
DB Time: 703.76 (mins)  

当然我们还是能够从AWR报告中发现一些端倪,以下这些SQL来自"SQL ordered by Cluster Wait Time"部分,可以根据顺序来评估那些在集群间存在等待的SQL,比如那些频繁执行的UPDATE更新,如果这些SQL在两个节点之间都执行频繁,则可能引起Remaster,出现GES的某些竞争,后台的定时任务也需要分析:


























































































Cluster Wait Time (s)Executions%TotalElapsed Time(s)%Clu%CPU%IOSQL IdSQL ModuleSQL Text
34.101557.366,957.260.4914.930.007yaqm2habcbap DECLARE job BINARY_INTEGER := ...
17.7516,3043.83103.9717.0785.250.006yva4jbyzfky5 select local_tran_id, state, s...
9.2211.99287.423.2152.822.48b6usrg82hwsa3DBMS_SCHEDULERcall dbms_stats.gather_databas...
6.05161.30371.151.6398.170.003zmj35k9fmct6 DECLARE job BINARY_INTEGER := ...
5.8559,4431.265,348.590.110.460.00ggu8pr7gjt8h2 UPDATE T_XHD_XHQPMX SET CHANGE...
5.4529,8001.18233.212.3497.470.000d2swsmcbg95n UPDATE T_DPLS SET WCXDCS = WCX...
3.9215,3670.8580.904.8521.940.005tn8hvpg71v9p UPDATE T_XHD_XHQPMX@C_LINK_SL_...


所以对于这个问题,我认为从两个节点来分头观察,可能有助于最终问题的发现和解决。


这个问题的AWR报告不完整,如下:


http://www.eygle.com/pdf/awrrpt_1_143_157.html





「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论