AWR報告閱讀提要

AWR（Automatic Workload Repository，自動工作負荷知識庫）是Oracle 10g開始推出的特性，它通過對比兩次快照（snapshot）收集的統計信息，生成有關實例和數據庫性能及健康狀況的統計報表。

選擇報表時間段很關鍵，要選擇能夠代表性能問題的時間段。如果快照周期不在這一段時間內，或者快照周期跨度太長而包含了大量的空閑時間，所得出的分析結果是沒有意義的。

以下是一個來自實際生產系統的AWR報告，下面以此例做個簡要介紹。

報頭

這里包含了主機實例和數據庫的最基本信息。報告包含快照的前后時間、會話數、數據庫運行總體時間消耗。主要看點就是對比時間消耗：

DB Time：非系統后臺進程所消耗的數據庫時間，即所有會話連接給數據庫帶來的時間消耗。即DB Time = CPU Time + Wait Time（不包含空閑等待）（非后臺進程）。

Elapsed：數據庫運行時間。

如果DB Time遠小于Elapsed，說明數據庫比較空閑，反之說明數據庫比較忙碌，壓力較大。

報告概要

這里顯示了數據庫各主要指標的統計信息，反映了數據庫的總體運行情況。

Cache Sizes

該部分說明了實例主要幾個內存塊的大小。

Buffer Cache：SGA中數據庫高速緩沖區緩存大小。

Shared Pool Size：SGA中共享池大小，包括庫緩存、數據字典緩存等。

Std Block Size：標準數據塊的大小。

Log Buffer：SGA中日志緩沖區大小。

Load Profile

該部分說明數據庫的負載概況，如果每秒或每事務的負載變化不大，說明應用運行比較穩定。單個的數據只說明應用的負載情況，大多數據并沒有一個所謂正確的值，應該通過對比來看其變化。

Redo size：每秒/每事務產生的日志大小（單位字節），反映數據變更頻率， 數據庫任務的繁重與否。

Logical reads：每秒/每事務產生的邏輯讀的塊數，Logical Reads= Consistent Gets + DB Block Gets。

Block changes：每秒/每事務修改的塊數。

Physical reads：每秒/每事務物理讀的塊數。

Physical writes：每秒/每事務物理寫的塊數。

User calls：每秒/每事務用戶調用次數。

Parses：每秒/每事務SQL語句解析次數，包括硬解析和軟解析。軟解析每秒超過300次意味著應用程序效率不高，硬解析則是指SQL語句未在內存中命中。

Hard parses：硬解析的次數，硬解析太多，說明SQL重用率不高。每秒硬解析次數超過100，說明綁定變量使用的不好，也可能是共享池設置不合理。

Sorts：每秒/每事務的排序次數。

Logons：每秒/每事務登錄的次數，如果會話登錄大于每秒1~2個，表明可能有爭用問題。

Executes：每秒/每事務SQL執行次數。

Transactions：每秒產生的事務數，反映數據庫任務繁重與否。

Blocks changed per Read：每次邏輯讀中更改的數據塊的百分比。

Recursive Call：遞歸調用所占比率，如果有很多PL/SQL，那么這個值就會比較高。

Rollback per transaction：每事務的回滾率，如果回滾率過高，說明數據庫經歷了過多的無效操作，過多的回滾可能會帶來Undo塊的競爭 。

Rows per Sort：平均每次排序的行數。

Instance Efficiency Percentages

該部分包含了Oracle關鍵指標的內存命中率及其它數據庫實例操作的效率，目標是100%。同Load Profile一節，這一節也沒有所謂正確的值，而只能根據應用的特點判斷是否合適。

Buffer Nowait：表示在緩存中獲得數據的未等待比例。該值一般需要大于99%。否則可能存在爭用，可以在后面的等待事件中進一步確認。 

Buffer Hit：表示進程在數據塊緩存中的讀塊命中率，監視這個值是否發生重大變化比這個值本身更重要。數據塊在數據緩沖區中的命中率通常應在95%以上。否則可能需要調整內存分配參數，增加內存等。一個高的命中率，不一定代表這個系統的性能是最優的，頻繁的訪問可能會造成命中率很高的假相，

但是一個比較低的命中率，一般就會對系統的性能產生影響，需要調整。命中率的突變，往往是一個不好的信息。如果命中率突然增大，可以檢查導致大量邏輯讀的語句，如果命中率突然減小，可以檢查產生大量物理讀的語句，主要是那些沒有使用索引的語句。

Llibrary Hit：表示Oracle從庫緩存中檢索到解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查庫緩存確定是否存在解析過的版本，如果存在，Oracle立即執行語句，如果不存在，Oracle解析此語句，并在庫緩存中為它分配共享SQL區。該值低表明存在過多的解析，增加CPU消耗，降低性能。如果低于90%，可能需要調大共享池、考慮使用綁定變量等。

Execute to Parse：語句執行與分析的比例，如果SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。

Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)。如果該比率為100%，意味著CPU解析過程沒有等待。

Redo NoWait：表示在日志緩沖區中獲得buffer的未等待比例。如果太低（參考90%閥值），考慮增加日志緩沖區大小，一般當redo buffer設置超過1M，不太可能存在等待buffer空間分配的情況。 

In-memory Sort：在內存中排序的比例，如果過低（參考95%閥值），說明有較多排序需要在臨時表空間中進行，這樣就會影響系統性能。

Soft Parse：軟解析的比例，可近似當作SQL在共享池的命中率，太低則需要調整使用綁定變量。SQL在共享池中的命中率小于<95%，需要考慮綁定，低于80%，就可以認為SQL基本沒有被重用。

Latch Hit：Latch是一種保護內存結構的鎖，可以認為是服務器進程獲取訪問內存數據結構的許可。

要確保Latch Hit>99%，否則意味著存在Latch爭用，可能由于未共享的SQL，或者庫緩存太小，可使用綁定變更或調大共享池解決。可借助后面的等待事件和Latch分析來查找問題。

Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，如果該值太低，則表示解析消耗時間過多。 

Shared Pool Statistics

該部分是共享池使用的統計信息。

Memory Usage：共享池內存使用率。對于一個已經運行了一段時間的數據庫，該值應該在75%-90%，如果太小，說明共享池有浪費，如果高于90%，說明共享池有爭用，內存不足。共享池設置過大會帶來額外管理上的負擔，從而影響系統性能。共享池過小會使組件過快老化，如果SQL語句再次執行，將使SQL語句被硬解析。

SQL with executions>1：執行次數大于1的SQL比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。

Memory for SQL w/exec>1：執行次數大于1的SQL消耗內存的占比，與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內存多少的一個度量。

Top 5 Timed Events 

這是報告概要的最后一節，顯示了系統中最嚴重的5個等待事件，按等待時間的比例倒序排列。應從這里入手，考慮下一步做什么。例如該報告顯示db file scattered read是最主要的等待，等待占比達到50%以上，說明存在大量的全表掃描未走索引的情況。通常在沒有問題的系統中，CPU time應該列在第一個，否則說明系統大部分時間都用在等待上了。

主要問題看點

Wait Events Statistics

等待事件統計能快速反映影響系統運行性能的主要等待。這里主要看Wait Events一節的統計。

該表按照等待的時間排名，最影響性能的等待事件位于前列。以下就常見的一些等待事件做一說明。

db file scattered read：數據文件分散讀。該等待事件典型地發生在全表掃描或全索引掃描上，反映了在讀取一組連續的數據塊時發生的I/O等待。如果該事件位于前列，說明可能有大量未走索引的SQL執行耗費了數據庫時間，此時可以結合后面的SQL Statistics的統計信息查找未走索引而全表掃描的SQL語句。

db file sequential read：數據文件順序讀。該事件典型地發生在索引查找或通過rowid訪問記錄上，反映了在讀取單個數據塊上的I/O等待。該值過高通常是由于表間連接順序不好，索引使用不當導致。

db file parallel write：緩存中的數據塊被DBWR進程并行地寫至磁盤時發生的I/O等待。該值高可能需要改善磁盤I/O性能。

log file parallel write：從日志緩沖區 寫日志記錄到聯機日志文件時發生。如果存在多個日志組成員，則寫操作是并行的，此時該等待事件可能出現。如果磁盤支持異步IO或者使用IO SLAVE，那么即使只有一個日志組成員，也有可能出現此等待。改善這個等待的方法是將聯機日志文件放到I/O快的磁盤中，盡量不使用RAID5陣列，確保表空間不是處在熱備模式下，確保日志文件和數據文件位于不同的磁盤上。

log file sync：等待LGWR進程將日志緩沖區的內容寫至磁盤時發生。此事件發生在用戶執行commit命令的時候。當用戶提交數據時，LGWR需要將會話的日志記錄從日志緩沖區填充到日志文件中，用戶的進程必須等待這個填充工作完成。如果這個等待事件影響到數據庫性能，那么就需要考慮修改應用程序的提交頻率，一次提交更多的記錄，或者將重做日志文件放在不同的物理磁盤上，避免使用RAID5陣列存儲聯機日志文件，提高磁盤I/O性能。

log buffer space：進程正在等待日志緩沖區的可用空間。典型地，該事件表明應用程序產生日志的速度超過了LGWR進程寫日志到磁盤上的速度。該事件較高時，因分析產生大量日志的原因，增大日志緩沖區，改善磁盤I/O性能。

control file parallel write / control file single write / control file sequential read：當服務器進程更新或讀取控制文件時發生該事件。如果等待很短，可以不用考慮。如果等待時間較長，應檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。多個控制文件是完全相同的拷貝，用于鏡像以提高安全性，因此應該存放在不同的磁盤上。在同一個磁盤上保存多個控制文件并不具備實際意義。減少這個等待，可以考慮在確保安全的前提下減少控制文件的個數，使用異步磁盤I/O，轉移控制文件到I/O負擔較輕的磁盤上。

enqueue：由于鎖機制而產生的隊列等待。典型地，如用戶試圖修改表中的一行數據，而此行數據正被其他用戶修改。

lach free：一個進程正在等待另一個進程持有的鎖存器釋放時發生該類等待事件。latch是一種能快速地被獲取和釋放的內存鎖，用于保護SGA中的共享內存結構，防止被多個用戶同時訪問。SQL語句沒有使用綁定變量、緩沖區存儲競爭、緩沖區存在熱點塊等諸多原因都可能會出現該事件。

direct path read / direct path write：進程不經過數據庫高速緩沖區緩存而直接讀寫磁盤數據塊時發生的I/O等待。典型地，排序操作、并行DML操作、直接路徑加載時發生該類等待。找到I/O 操作最為頻繁的數據文件，如果有過多的排序操作，很可能就是臨時文件，分散其負載，改善I/O性能。

SQL*Net message from client：表明用戶會話的服務器進程已經完成一個用戶請求，正在等待用戶的下一個請求時發生的等待事件。

SQL Statistics

SQL統計查看影響系統運行性能的、比較耗時的SQL。這里優先看SQL ordered by Elapsed Time，按照執行SQL語句消耗的時間進行了排序。

如這里可以看出OPU條碼打印程序執行的一段SQL消耗了大量的數據庫時間，遠遠高于其他語句。點擊SQL Id，頁面跳轉到該問題語句：

這是根據SN對WIP_TRACKING表執行的全字段查詢。結合前面對等待事件的分析，由于同時存在大量的db file scattered read等待事件，因此估計該語句可能沒有走索引，執行了全表掃描，導致嚴重的性能問題。將該語句單獨拿出來看其執行計劃，可以驗證確實存在不走索引的情況，執行時間超過幾秒以上。另外可以看到該查詢雖然執行次數較多（Executions），但沒有使用綁定變量，會導致頻繁的硬解析。找到產生該問題語句的源頭，結果我們發現它來自于OPU條碼打印程序包里的config.xml文件，執行該語句的目的是隨線打印時判斷上一張條碼是否已上線，前一個SN上線后才允許吐下一張條碼。從業務功能上可以看出，完全沒有必要做select *的操作，使用select 1 from rmes.r_wip_tracking_t where sn = ‘…’將會是更好的方法。

從這里還可以看到其它一些影響的語句，BoschPDC_SQLPUSH_ICON_MySQLPush_V3來自于BOSCH程序，w3wp來自于Web程序，也可以看到FlexSite執行的主要耗時的存儲過程和語句。

其它幾種SQL統計簡述如下：

SQL ordered by CPU Time：通過SQL語句在CPU運行時間上的消耗來排序，不包含執行SQL語句過程中的各類等待時間。

SQL ordered by Gets：通過SQL語句執行了多少邏輯讀來排序。可以對比該條語句的Buffer Gets和后面統計的physical reads，如果兩個比較接近，說明該語句存在問題。另外，我們在這里也可以關注gets per exec的值，這個值如果太大，表明這條語句可能使用了一個比較差的索引或者使用了不當的表連接。

SQL ordered by Reads：通過SQL語句執行了多少物理讀來排序。這顯示引起大部分物理I/O的SQL，當我們的系統存在I/O瓶頸時，需要關注這里I/O操作比較多的語句。效率低下的SQL往往伴隨著大量的物理讀，從而也造成了大量的數據塊分散讀等待。

SQL ordered by Executions：這里告訴我們這段時間中執行次數最多的SQL語句。可以考慮是否有必要更改邏輯，避免太過次數的查詢。即使運行的很快，但被大量重復的操作都可能會消耗較多的數據庫時間。

SQL ordered by Parse Calls：這里主要顯示解析（Parse）與執行（Executions）的對比情況。如果Parse / Executions > 1，往往說明這個語句存在問題，如沒有使用綁定變量，另外可能共享池設置太小等。

SQL ordered by Sharable Memory：這里主要是針對共享池的占用情況進行排序。

SQL ordered by Version Count：這里主要是針對SQL語句存在的多版本進行排序。相同的SQL文本，但屬性可能不同，如對象的擁有者不同、會話優化模式不同、類型不同、長度不同、綁定變量不同等的SQL語句是不能共享的，所以在緩存中會存在多個不同的版本，當然也就造成了資源上的更多消耗。