AWR报告分析之二:ges inquiry response 过高
在一个朋友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 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 NamePlatformCPUsCoresSocketsMemory (GB)
SDSLDB1
Linux x86 64-bit
160
80
8
504.72
Snap IdSnap TimeSessionsCursors/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%TotalElapsed Time(s)%Clu%CPU%IOSQL IdSQL ModuleSQL Text
34.10
155
7.36
6,957.26
0.49
14.93
0.00
DECLARE job BINARY_INTEGER := ...
17.75
16,304
3.83
103.97
17.07
85.25
0.00
select local_tran_id, state, s...
9.22
1
1.99
287.42
3.21
52.82
2.48
DBMS_SCHEDULER
call dbms_stats.gather_databas...
6.05
16
1.30
371.15
1.63
98.17
0.00
DECLARE job BINARY_INTEGER := ...
5.85
59,443
1.26
5,348.59
0.11
0.46
0.00
UPDATE T_XHD_XHQPMX SET CHANGE...
5.45
29,800
1.18
233.21
2.34
97.47
0.00
UPDATE T_DPLS SET WCXDCS = WCX...
3.92
15,367
0.85
80.90
4.85
21.94
0.00
UPDATE T_XHD_XHQPMX@C_LINK_SL_...
所以对于这个问题,我认为从两个节点来分头观察,可能有助于最终问题的发现和解决。
这个问题的AWR报告不完整,如下:
By eygle on 2012-11-26 08:16 |
Comments (0) |
Case | 3060 |