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.
這個報告的主要等待如下:
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 | 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報告不完整,如下:
----------------------------------------------->>
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29119536/viewspace-1147545/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- AWR報告分析之二:ges inquiry response 過高-eygleUI
- AWR解析報告分析
- 手工生成AWR分析報告
- oracle AWR報告提取分析Oracle
- ORACLE AWR報告詳細分析Oracle
- awr診斷分析之二
- AWR報告分析之一:高 DB CPU 消耗的效能根源-eygle
- Oracle AWR報告分析之–SQL ordered byOracleSQL
- Oracle 10g AWR 報告分析Oracle 10g
- Oracle的AWR報告分析(簡潔版)Oracle
- Oracle_AWR報告分析指南(經典版)Oracle
- 對於AWR報告的幾個片段分析。
- AWR 報告修改moving window 出錯分析
- Oracle生成awr報告Oracle
- mysql-awr報告MySql
- Oracle 生成awr報告Oracle
- oracle效能awr報告Oracle
- Oracle的AWR報告分析(經典串聯版)Oracle
- 關於類似於awr的效能分析報告
- Oracle AWR 介紹及報告分析(2) finalOracle
- Oracle AWR 介紹及報告分析(1) finalOracle
- 【AWR】Oracle批量生成awr報告指令碼Oracle指令碼
- AWR報告分析之三:cursor: pin S 的原理與案例分析
- 通過AWR報告處理故障一次心得
- AWR報告基礎操作
- Oracle AWR報告大綱Oracle
- oracle 產生awr 報告Oracle
- AWR報告分析之三:cursor: pin S 的原理與案例分析-eygle
- 【AWR】自動生成AWR報告指令碼以及用法指令碼
- 【深度長文】循序漸進解讀Oracle AWR效能分析報告Oracle
- AWR報告的收集和分析執行計劃的方式
- 生成awr報告的指令碼指令碼
- 詳細的AWR解析報告
- 自動生成AWR HTML報告HTML
- oracle特性之AWR報告2Oracle
- 快捷生出awr和awrsql報告SQL
- 一次awr報告分析(密碼錯誤引發sql執行時間過長)密碼SQL
- 通過shell指令碼抓取awr報告中的問題sql指令碼SQL