在一個朋友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 Module	SQL 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報告不完整，如下：

--&gt>轉載於:

AWR報告分析之二：ges inquiry response 過高-eygle

相關文章