1. 程式人生 > 實用技巧 >快速熟悉 Oracle AWR 報告解讀

快速熟悉 Oracle AWR 報告解讀

目錄

本文面向沒有太多 Oracle 基礎知識,但是需要通過 AWR 報告來分析資料庫效能或排查問題人員,通過對 AWR 報告的簡介,瞭解其包含的主要資訊,然後對一些能夠幫助我們分析定位問題的章節做一點稍微詳細的介紹。通過閱讀本文,期望使讀者能夠快速抓住閱讀 AWR 報告的重點,為分析判斷資料庫效能是否有問題提供幫助。

本文示例報告基於 Oracle 11.2.0.3.0 版本生成。

AWR報告簡介

AWR是Oracle 10g版本推出的特性,全稱叫做 Automatic Workload Repository 全自動負載資訊庫

。Oracle啟動後,會有後臺程序定時採集並儲存系統快照資訊,也可以手工建立快照。AWR通過對比兩個時間點的快照資訊,生成該時間段的AWR報告,幫助DBA或開發人員瞭解 Oracle 資料庫的執行情況。Oracle 還提供了 ASH、ADDM等工具,本文不進行探討。

AWR報告結構

AWR報告基本分為四部分:

  • 基本資訊部分,包括了DB例項、主機的資訊以及報告採集時間段的資訊。
  • Main Report部分,第一部分Report Summary被單獨放在了基本資訊後面,其他的資訊則放在整個報告較後的位置,個人覺得最重要的部分是SQL Statistcs。
  • RAC statistics部分,包括RAC相關的統計資訊。
  • Wait Event Statistics部分。

基本資訊

報告一開始部分為基本資訊,顯示了DB例項、主機資訊。DB Time 指標可以用來判斷資料庫是否繁忙,如果 Elapsed 時間乘以CPU個數小於DB Time 表示資料庫比較繁忙。

Report Summary

Report Summary 分為8個部分,最主要的是 Load Profile。

Load Profile 主要用來顯示當前系統的一些指示效能的總體引數,部分介紹如下:

  • Redo Size :用來顯示平均每秒的日誌大小和平均每個事務的日誌大小,有時候可以結合 Transactions 每秒事務數,分析當前事務的繁忙程度
  • Logical Read:邏輯讀耗CPU,主頻和CPU核數都很重要,邏輯讀高則DB CPU往往高,也往往可以看到 latch: cache buffer chains 等待。
  • Physical Read:物理讀消耗IO讀,體現在IOPS和吞吐量等不同緯度上。但減少物理讀可能意味著消耗更多CPU。
  • Parses:解析次數,包括軟解析 + 硬解析,軟解析優化得不好幾乎等於每秒SQL執行次數, 即執行解析比1:1。理想狀態是解析一次到處執行。
  • Hard Parses:硬解析次數,最好少於沒秒20次。

注意 Load Profile 中的指標提供了 Per second 和 Per transaction 兩個維度。Per second 主要是把快照抓到的值除以兩個快照之間的秒數。這是我們用來判斷效能的主要維度。Per transaction 是基於事務的維度,主要是把快照抓到的值除以兩個快照之間的事務數。

Instance Efficiency Percentages 是一些命中率指標。Buffer Hit、Library Hit 等表示SGA ( System global area )的命中率。Soft Parse 指標表示共享池的軟解析率,如果小於90%,就說明存在未繫結變數的情況。這些指標應當儘可能接近100%,如果過低一定是發生了效能問題。

  • Buffer Nowait ** 表示在記憶體獲得資料的未等待比例。在緩衝區中獲取Buffer的未等待比率。Buffer Nowait的這個值一般需要大於99%**。否則可能存在爭用,可以在後面的等待事件中進一步確認。
  • Buffer Hit 表示程序從記憶體中找到資料塊的比率,監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統,如果此值低於80%,應該給資料庫分配更多的記憶體。資料塊在資料緩衝區中的命中率,通常應在95%以上。
  • Redo NoWait 表示在Log 緩衝區獲得Buffer的未等待比例。如果太低可考慮增加Log Buffer。當redo buffer達到1M時就需要寫到redo log檔案,所以一般當redo buffer設定超過1M,不太可能存在等待buffer空間分配的情況。當前,一般設定為2M的redo buffer,對於記憶體總量來說,應該不是一個太大的值。
  • Library Hit 表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率,當應用程式呼叫SQL或儲存過程時,Oracle檢查Library Cache確定是否存在解析過的版本,如果存在Oracle立即執行語句;如果不存在Oracle解析此語句,並在Library Cache中為它分配共享SQL區。低的Library Hit Ratio會導致過多的解析,增加CPU消耗,降低效能。如果Library Hit Ratio低於90%,可能需要調大Shared pool區。
  • Latch Hit:Latch是一種保護記憶體結構的鎖,可以認為是Server程序獲取訪問記憶體資料結構的許可。要確保Latch Hit>99%,否則意味著Shared Pool latch爭用,可能由於未共享的SQL,或者Library Cache太小,可使用繫結變更或調大Shared Pool解決。要確保>99%,否則存在嚴重的效能問題。當該值出現問題的時候,我們可以藉助後面的等待時間和latch分析來查詢解決問題。
  • Parse CPU to Parse Elapsd:解析實際執行時間/(解析實際執行時間+解析中等待資源時間),越高越好。如果該比率為100%,意味著CPU等待時間為0,沒有任何等待。
  • Non-Parse CPU :SQL實際執行時間/(SQL實際執行時間+SQL解析時間),太低表示解析消耗時間過多。如果這個值比較小,表示解析消耗的CPU時間過多。
  • Execute to Parse:是語句執行與分析的比例,如果要SQL重用率高,則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。
  • In-memory Sort:在記憶體中排序的比率,如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA(10g)。如果低於95%,可以通過適當調大初始化引數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決,注意這兩個引數設定作用的範圍時不同的,SORT_AREA_SIZE是針對每個session設定的,PGA_AGGREGATE_TARGET則時針對所有的sesion的。
  • Soft Parse:軟解析的百分比(Softs/Softs+Hards),近似當作sql在共享區的命中率,太低則需要調整應用使用繫結變數。sql在共享區的命中率,小於<95%,需要考慮繫結,如果低於80%,那麼就可以認為sql基本沒有被重用。

Main Report

  • Report Summary 在上面一節已經說過,不再贅述。
  • SQL Statistics 從 11 個維度對SQL進行排序並給出了Top SQL的詳細內容,可以點選檢視具體的SQL內容,進一步分析調優方案。
    • SQL ordered by Elapsed Time。記錄了執行總和時間的 TOP SQL(請注意是監控範圍內該SQL的執行時間總和,而不是單次SQL執行時間 Elapsed Time = CPU Time + Wait Time)。
    • SQL ordered by CPU Time。記錄了執行佔CPU時間總和時間最長的TOP SQL(請注意是監控範圍內該SQL的執行佔CPU時間總和,而不是單次SQL執行時間)。
    • SQL ordered by Gets。記錄了執行佔總 buffer gets (邏輯IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔Gets總和,而不是單次SQL執行所佔的Gets)。
    • SQL ordered by Reads。記錄了執行佔總磁碟物理讀(物理IO)的TOP SQL。
    • SQL ordered by Executions。記錄了按照SQL的執行次數排序的TOP SQL。該排序可以看出監控範圍內的SQL執行次數。
    • SQL ordered by Parse Calls。記錄了SQL的軟解析次數的TOP SQL。
    • SQL ordered by Sharable Memory。記錄了SQL佔用library cache的大小的TOP SQL。Sharable Mem (b):佔用library cache的大小,單位是byte。
    • SQL ordered by Version Count。記錄了SQL的開啟子游標的TOP SQL。
    • SQL ordered by Cluster Wait Time。記錄了叢集的等待時間的TOP SQL。
  • Top 10 Foreground Events by Total Wait Time,等待事件是衡量資料庫優化情況的重要指標,通過觀察Event和%DB time兩列就可以直觀看出當前資料庫的主要等待事件。

RAC statistics

這一部分涉及RAC執行的相關統計資訊,對於初學者來說不太常用,本文暫不贅述。

Wait Event Statistics

其中 Time Model Statistics 幾個有用的指標解釋如下:

  • parse time elapsed 與 hard parse elapsed time 需要結合起來看解析是否是主要矛盾,若是則重點是軟解析還是硬解析。
  • sequence load elapsed time 序列爭用
  • PL/SQL compilation elapsed time PL/SQL物件編譯的耗時
  • connection management call elapsed time 資料庫連線建立和斷開的耗時
  • failed parse elapsed time 解析失敗的耗時

參考資料

  1. oracle11G AWR使用及分析
  2. 等待事件:db file scattered read(離散讀)
  3. 【深度長文】循序漸進解讀Oracle AWR效能分析報告
  4. Oracle AWR報告生成和效能分析
  5. Oracle AWR報告指標全解析