與IO相關的等待事件troubleshooting-系列2

Troubleshooting步驟：

Troubleshooting與IO相關的等待：

資料庫性能調優方面一項關鍵的方法就是響應時間分析。找出時間都花費在資料庫的哪些環節。

時間是性能調優中最重要的屬性。使用者通過交易或批處理任務的響應時間來感覺系統的性能。

Oracle的響應時間分析使用如下公式：

Response Time = Service Time + Wait Time

響應時間=服務處理時間+等待時間

‘服務處理時間’使用‘CPU used by this session’統計資料來衡量。

‘等待時間’則是所有等待事件用時之和。

注：盡管很像，但這個公式絕對不是排隊理論的基礎公式。

通過分析總體響應時間不同元件的相對影響，可以使用AWR或statspack這樣的工具進行性能調優，将調優的精力放到最消耗時間的元件中。

判斷IO等待事件的真實重要性：

        包括AWR和Statspack在内的許多工具都可以列出最重要的等待事件。Oracle 9i R2的Statspack報告之前的版本包含在了"Top 5 Wait Events"節。

        當看到這樣的top等待事件清單，通常就會很容易地開始處理這些等待事件，但往往忽視了首先可以分析下他們對總體響應時間的影響。

        “Service Time”(例如CPU的使用)要遠比“Wait Time”更重要，分析這些等待事件不會對節省“響應時間”有幫助。

        是以，應該将top等待事件花費的時間與“CPU used by this session”對比，将調優的精力放到最需要的地方。

        從Oracle 9i R2開始，“Top 5 Wait Events”已經改名為“Top 5 Timed Events”，通過統計session所用的CPU來衡量“Service Time”，并列到“CPU time”中。這就意味着可以更容易、更準确地衡量等待事件對總體“響應時間”的影響，正确地指導接下來的調優方向。

錯誤了解等待事件的影響：執行個體

        接下來的兩個真實案例說明了為什麼需要檢視“Wait Time”和"Service Time"兩部分，對分析資料庫性能的重要性。

執行個體1：Oracle 9i R2之前的Statspack

        下面是産生自46分鐘的兩個snapshot之間的Statspack報告“Top 5 Wait Events”節：

        從以上的清單，我們很可能傾向于立即開始查找“direct path read”和“db file scattered read”等待之間的原因，嘗試調優他們。這種方法沒有考慮到“Service Time”。

        從同一份報告中得到的“Service Time”如下：

        讓我們來做一下簡單的計算：

'Wait Time' = 10,827 x 100% / 52,01% = 20,817 cs

'Service Time' = 358,806 cs

'Response Time' = 358,806 + 20,817 = 379,623 cs

        如果現在我們來計算所有“Response Time”元件的百分比：

        現在就明顯了，與IO相關的等待事件對于總體響應時間來說并不是真正耗時的元件(少于6%)，是以解析來的調優應該聚焦在服務處理時間元件上，例如CPU消耗。

執行個體2：Oracle 10i R2之後的AWR

注意：類似的資訊也會顯示在Oracle 9i R2以後的Statspack報告：

        在AWR中，更容易看到CPU是最耗費時間的，因為CPU元件也包括在“Top 5 Timed Foreground Events”節。從上面的例子，我們能夠再次看到等待事件的用時少于20%，家下來的調優重點應該放在服務處理時間的元件上，例如CPU消耗。

(未完待續)