« 嘉年华回眸:商圈网CTO丁晓强-复杂系统的运维平衡之道 | Blog首页 | Oracle云数据库初体验 之一 - 申请与介绍 »
AWR报告分析之二:ges inquiry response 过高
链接:https://www.eygle.com/archives/2012/11/ges_inquiry_response.html
在一个朋友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.
这个报告的主要等待如下:
Event | Waits | Time(s) | Avg wait (ms) | % DB time | Wait Class |
---|---|---|---|---|---|
DB CPU | 18,228 | 43.17 | |||
ges inquiry response | 49,384,771 | 13,890 | 0 | 32.89 | Other |
transaction | 5,314 | 5,317 | 1001 | 12.59 | Other |
SQL*Net message from dblink | 1,271,667 | 1,365 | 1 | 3.23 | Network |
PX Nsq: PQ load info query | 5,773 | 1,135 | 197 | 2.69 | Other |
但是实际上,这个报告的时间跨度过大(跨度为14小时),这里的等待可能不足以说明问题,以下数据显示服务器主机非常强劲,有160 CPUs和500G内存:
Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
---|---|---|---|---|---|
SDSLDB1 | Linux x86 64-bit | 160 | 80 | 8 | 504.72 |
Snap Id | Snap Time | Sessions | Cursors/Session | |
---|---|---|---|---|
Begin Snap: | 143 | 22-Nov-12 09:00:30 | 90 | 1.5 |
End Snap: | 157 | 22-Nov-12 23:00:44 | 73 | .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 | %Total | Elapsed Time(s) | %Clu | %CPU | %IO | SQL Id | SQL Module | SQL Text |
---|---|---|---|---|---|---|---|---|---|
34.10 | 155 | 7.36 | 6,957.26 | 0.49 | 14.93 | 0.00 | 7yaqm2habcbap | DECLARE job BINARY_INTEGER := ... | |
17.75 | 16,304 | 3.83 | 103.97 | 17.07 | 85.25 | 0.00 | 6yva4jbyzfky5 | select local_tran_id, state, s... | |
9.22 | 1 | 1.99 | 287.42 | 3.21 | 52.82 | 2.48 | b6usrg82hwsa3 | DBMS_SCHEDULER | call dbms_stats.gather_databas... |
6.05 | 16 | 1.30 | 371.15 | 1.63 | 98.17 | 0.00 | 3zmj35k9fmct6 | DECLARE job BINARY_INTEGER := ... | |
5.85 | 59,443 | 1.26 | 5,348.59 | 0.11 | 0.46 | 0.00 | ggu8pr7gjt8h2 | UPDATE T_XHD_XHQPMX SET CHANGE... | |
5.45 | 29,800 | 1.18 | 233.21 | 2.34 | 97.47 | 0.00 | 0d2swsmcbg95n | UPDATE T_DPLS SET WCXDCS = WCX... | |
3.92 | 15,367 | 0.85 | 80.90 | 4.85 | 21.94 | 0.00 | 5tn8hvpg71v9p | UPDATE T_XHD_XHQPMX@C_LINK_SL_... |
所以对于这个问题,我认为从两个节点来分头观察,可能有助于最终问题的发现和解决。
这个问题的AWR报告不完整,如下:
http://www.eygle.com/pdf/awrrpt_1_143_157.html
历史上的今天...
>> 2014-11-26文章:
>> 2009-11-26文章:
>> 2005-11-26文章:
>> 2004-11-26文章:
By eygle on 2012-11-26 08:16 | Comments (0) | Case | 3060 |