@?/rdbms/admin/awrrpt.sql

http://blog.itpub.net/31397003/viewspace-2138943/

等待事件（入口）-->db file sequential read （如果時間比較久排名靠前）-->索引 -->I/O問題 -->SQL語句
思路：面-->線-->點

DB Time 大於Elapsed Time，是因為它是所有使用者執行時間總和。

Instance Efficiency Percentages (Target 100%)

本節包含了Oracle關鍵指標的記憶體命中率及其它資料庫例項操作的效率。其中Buffer Hit Ratio 也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節相同，這一節也沒有所謂“正確”的值，而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型並行查詢的DSS環境，20%的Buffer Hit Ratio是可以接受的，而這個值對於一個OLTP系統是完全不能接受的。根據Oracle的經驗，對於OLTPT系統，Buffer Hit Ratio理想應該在90%以上。

Buffer Nowait%表示在資料緩衝區中獲取的buffer時，未進行等待的比率，越高越好。

buffer hit%表示程序從記憶體中找到資料塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，命中率通常在[email protected]以上，如果此值低於80%，應該給資料庫分配更多的記憶體，考慮加大db_cache_size。在資料倉庫OLAP環境中，資料緩衝命中率不是一個重要的指標，因為OLAP資料庫主要是物理讀，甚至是直接讀，該命中率不可能高。

Redo NoWai%t表示在LOG緩衝區獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。

library hit%表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程式呼叫SQL或儲存過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，並在Library Cache中為它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低效能。Sql語句在庫緩衝中能否找到相應的解析計劃，如果library hit ratio低於90%，可能需要調大shared pool區，或檢查是否有硬編碼現象。

Latch Hit%：Latch是一種保護記憶體結構的鎖，可以認為是SERVER程序獲取訪問記憶體資料結構的許可,表示內部結構維護鎖命中率。要確保Latch Hit>99%，否則意味著Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用繫結變更或調大Shared Pool解決。

Parse CPU to Parse Elapsd：表示解析實際執行時間/(解析實際執行時間+解析中等待資源時間)，越高越好。在實際繁忙的系統中，該值可能因為等待資源而不會太高。

Non-Parse CPU ：SQL實際執行時間/(SQL實際執行時間+SQL解析時間)，太低表示解析消耗時間過多。說明解析時間所佔比率過高，需要考慮提高sql語句重用性。

Execute to Parse：是語句執行與分析的比例,表示sql語句解析後被重複執行的命中率，計算公式=100*（1-Parses/Executions）,如果該值偏小，說明分析（硬分析和軟分析）的比例較大，快速分析較少，根據實際情況，可以考慮調整session_cached_cursors引數，有些報告中這個值是負的，看上去很奇怪，事實上這表示一個問題，sql如果被age out的話就可能出現這種情況 ，也就是sql老化，執行alter system flush shared_pool

如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。

  Soft Parse%：SQL語句軟解析佔整個分析的命中率，如果低於95，需檢查是否有硬編碼現象，如果低於80，說明sql語句基本沒有重用性=soft/(soft+hard)

In-memory Sort：在記憶體中排序的比率，即有多少排序在記憶體中進行的，如果過低說明有大量的排序在臨時表空間中進行，效能肯定不好，考慮調大PGA引數，sort_area_size。

Soft Parse：軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用繫結變數。

SQL Statistics

SQL ordered by Elapsed Time：記錄了執行總時間最長的Top SQL，其中Elapsed Time = CPU Time + Wait Time

-------------------------------------------------------------------

CPU Time 指的是CPU在忙於執行當前任務的時間，其並沒有考慮等待時間，如IO等待，網路等待等，而Elapsed Time 則是執行當前任務所花費的總時間，也就是說這兩者之

問的關係統可以表示為：Elapsed Time = Cpu Time + Wait Time 但是在多核處理器的情況下，由於多個CPU同時處理任務所以可能會出現Cpu Time 大於Elapsed Time 的情況

• CPU Time：對於單執行緒程式來說，CPU TIME指的是該執行緒在一個邏輯處理器（單核）上所花費的時間總量；對於多執行緒程式來說，CPU TIME指的是所有執行緒的CPU TIME之和；應用程式的CPU時間指的是該程式所有執行緒的CPU TIME之和。
• Wait Time：特定執行緒等待一定事件發生的時間，這些事件可以是同步等待，I/O等待。
• Elapsed time:該程式執行的平臺時間，即：應用程式結束的時刻-應用程式起始時刻。

通過下面這個例子能夠更好的說明幾個概念之間的區別：

從這張圖中，我們可以看到一共有三個執行緒，Thread1，Thread2，Thread3，其分別的起始時刻為0,1,2。則統計：

• Elapsed time: 程式共執行6秒，故Elapsed time為6sec；
• Cpu time:對於多執行緒程式，其cpu time為所有執行緒時間之和，故cpu time=1+3+2+2=8sec;
• Wait time：等待時間，故wait time=2+3+2=7sec;

值得注意的是：Elapsed
time, Cpu time, Wait time這三者並沒有大小關係，比如並不一定elapsed time就一定大於cpu time；

總結一下：

• 對於單執行緒程式，cpu time, wait time可能或等於elapsed time。
• 對於多執行緒程式，elapsed time有可能比另外二者大，也有可能小，關鍵在於到底有多少個執行緒在執行和這些執行緒的執行狀態。

-----------------------------------------------------------

SQL ordered by CPU Time：記錄了佔CPU時間最長的Top SQL

SQL ordered by User I/O Wait Time：記錄了執行過程中等待IO時間最長的Top SQL

SQL ordered by Gets：記錄了執行最多邏輯讀（邏輯IO）的Top SQL

通常我們可以通過對比該條語句的Buffer Gets和physical reads值，如果這兩個比較接近，肯定這條語句是存在問題的，我們可以通過執行計劃來分析，為什麼physical reads的值如此之高。另外，我們在這裡也可以關注gets per exec的值，這個值如果太大，表明這條語句可能使用了一個比較差的索引或者使用了不當的表連線。

SQL ordered by Reads：記錄了執行最多物理讀（物理IO）的Top SQL

SQL ordered by Executions：記錄了執行次數最多的Top SQL，即使單條SQL執行速度飛快，任何被執行幾百萬次的操作都將耗用大量的時間。

SQL ordered by Parse Calls：記錄了軟解析次數最多的Top SQL

在這一部分，主要顯示PARSE與EXECUTIONS的對比情況。如果PARSE/EXECUTIONS>1，往往說明這個語句可能存在問題：沒有使用繫結變數，共享池設定太小，cursor_sharing被設定為exact，沒有設定session_cached_cursors等等問題。

-----------------------------------------------------------華麗分割符-----------------------------------------

解讀AWR報告Advisory Statistics

      對於Oracle的記憶體引數的設定存在很多爭議，當然具體的設定需要根據系統的情況進行調整，不能一概而論，因此記憶體引數的設定也就成為了一個難點。但是Oracle 10g、11g的自動記憶體管理功能還是很強大的，對於負載一般的系統，即使記憶體引數設定不太合理，也是足以支撐系統正常執行的。下面就AWR報告中給出的幾個關鍵記憶體引數的建議章節進行解讀。
    一、 Buffer Pool Advisory部分：

         欄位解釋：P                          池型別
                                                        'D' - Default buffer cache (always present), 
                                                        'K' - Keep buffer cache (if db_keep_cache_size parameter is defined), 
                                                        'R' - Recycle buffer cache (if db_recycle_cache_size parameter is defined), 
                                                        - Caches for non-default block sizes (if defined with parameters db_k_cache_size) 
                           Size for Est(M)            Oracle估算Buffer pool的大小
                           Size Factor                        估算值和實際值的一個比例，比如0.9就是估算值是實際大小的90%，1.0表示buffer pool的實際大小
                           Buffers for Estimate           估算的buffer的大小（數量）
                           Est Phys Read Factor         估算的物理讀的影響因子，即物理讀和實際物理讀的一個比例，1.0表示實際的物理讀
                           Estimated Physical Reads   估算的物理讀次數
        這部分，主要從Size Factor、Est Phys Read Factor 都等於1.00的行開始，然後往上看，觀察當Size Factor減小時，Est Phys Read Factor是不是明顯變化，如果變化不明顯，說明可以減小當前的buffer pool設定，相反則表示不能減小；然後往下看，觀察當Size Factor增大時，Est Phys Read Factor是不是明顯變化，如果變化不明顯，說明沒必要增大buffer pool設定，相反，則表示增大buffer pool可以提高系統性能。如上面的例子，則可以將buffer pool減小一半。（Estimated Phys Reads ）
      
       二、Shared Pool Advisory

         欄位解釋：Shared Pool Size(M)          估算共享池的大小
                            SP Size Factr                     估算共享池的影響因子
                            Est LC Size (M)                  估算的庫快取記憶體佔用的大小（LC，library cache）
                            Est LC Mem Obj                高速緩衝區命中的物件數
                            Est LC Time Saved (s)        需要額外將物件讀入共享池的時間
                            Est LC Time Saved Factr     影響因子
                            Est LC Load Time (s)          分析所花費的時間
                            Est LC Load Time Factr       分析花費時間事件的影響因子
                            Est LC Mem Obj Hits           記憶體中物件被發現的次數
        與Buffer Pool Advisory類似，從 SP Size Factr = 1.00的行開始，上下觀察，當減小或增大shared pool時對Est LC Time Saved (s)的影響是否明顯。
  
        三、PGA Memory Advisory

          欄位解釋：PGA Target Est (MB)            PGA的估算大小
                            Size Factr                             影響因子，作用和buffer pool相同
                            W/A MB Processed               Oracle為了產生估算處理的資料量
                            Estd Extra W/A MB               處理資料中需要物理讀寫的資料量
                            Estd PGA Cache Hit %          估算的PGA命中率
                            Estd PGA Overalloc Count     需要在估算的PGA大小額外分配記憶體的次數
         同理，從 Size Factr  = 1.00的行開始，上下觀察當減小或增大pga的時候對Estd Extra W/A MB Read/Written to Disk的影響是否明顯。
          
         四、SGA Target Advisory

        欄位解釋：SGA Target Size (M)    估算SGA大小
                          SGA Size Factor            SGA大小的影響因子
                          Est DB Time (s)            估算的SGA大小計算出的DB Time
                          Est Physical Reads        物理讀次數
       從SGA Size Factor = 1.00的行開始，上下觀察減小或增大SGA時對 Est Physical Reads的影響是否明顯。