Oracle AWR 介紹及報告分析(2) final

因公司禁止上傳檔案， 故AWR報告未能上傳 。根據描述可以知道對應的欄位。

db time= cpu time + wait time（不包含空閒等待） （非後臺程式）， 就是db time就是記錄的伺服器花在資料庫運算(非後臺程式)和等待(非空閒等待)上的時間 

 

系統為24核CPU , 在snapshot間隔中，總共約1380.04分鐘，CPU時間共有1380.4*24=33129.6分鐘，這裡的DB time為2591.15分鐘，表示cpu花費了2591.15分鐘在處理Oracle非空閒等待和運算上(比方邏輯讀)
也就是說cpu有 2591.15/33129.6*100% (的百分比: 7.82%)花費在處理Oracle的操作上，這不包括後臺程式, 這臺伺服器的平均負載相對較低。從awr report的Elapsed 和DB Time就能大概瞭解db的負載.

就是說：  透過 DB Time / (Elapsed * CPU核數) *100% 得出的值就說明瞭CPU花費在處理Oracle的操作上的比例 (不包括後臺程式)。  比例越高，說明負載越高。

 

Load Profile 說明了目前庫整體狀態。

 

Redo size :  平均每秒或每事務重做產生的日誌大小為161K  (單位：Bytes) ，每事務產生5K重做日誌。

Physical  writes:  平均每秒物理寫為 66.52 blocks . 

Physical reads / Logical reads = 430.48 / 38788.19 = 1.1% 的邏輯讀導致了物理I/O。平均每個事物產生邏輯讀 1351.11 (blocks) 。這個數字應該越小越好。 Read的單位是block .

 Parses :     CPU每秒需要進行 1454.21 次解析，系統比較繁忙，每秒有35.79次硬解析(硬解析佔比例2.5% ) ，說明 1/35.79 = 0.02 秒CPU就要處理一個新的SQL語句，說明系統內不同SQL語句較多，建議多使用繫結變數及procedure處理。

 

Sorts:  每秒70.30次排序也是比較多的。

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

% Blocks changed per Read： 說明 1-2.43%=97.57% 的邏輯讀是用於那些只讀的而不是可修改的塊， 平均每次操作只更新佔2.43% 的塊 。也就是 ( 收集快照的這23個小時中 ) DML更新操作的塊佔整個被操作(邏輯讀)的塊的比例是2.43% 。

 

Recursive Call%  :    表示71.77%的SQL都是透過PL/SQL來執行的。Recursive：遞迴的

 

Rollback per transaction %：   表示事務回滾的百分比，越小越好。 19.95值已經非常高了(表示每個事物產生0.1995個回滾)，系統存在回滾方面的問題，因為回滾的代價非常昂貴，即平均每5（1/0.1995）個事務就要產生一次回滾 。 結合前面的transactions 每秒為 28.71個，即每秒會有28.71/5 = 5.7 次回滾。 應該仔細檢查系統為何產生如此高的回滾率。

 

資料庫例項效率。目標值都是100% 。

 

Buffer Nowait % ： 在緩衝區中獲取Buffer的未等待比率(buffer cache請求的命中率)，如果Buffer Nowait<99% 說明，有可能是有熱塊 (查詢x$bh的 tch和v$latch_children的cache buffers chains)。

Redo NoWait %： 在Redo緩衝區獲取Buffer的未等待比率。

Buffer Hit %： 資料塊在資料緩衝區中的命中率，通常應在95%以上，否則，小於95%，需要調整重要的引數，小於90%可能是要加db_cache_size，但是大量的非選擇的索引也會造成該值很高（大量的db file sequential read）。

 In-memory Sort %：在記憶體中的排序率。如果太低，需要考慮增加PGA或檢查程式減少排序。

Library Hit %：主要代表SQL在共享區(庫快取)的命中率，通常在95%以上，否則需要考慮加大Shared Pool ，繫結變數，修改cursor_sharing (需要謹慎修改此引數) 等引數。

Soft Parse %：  軟解析百分比，近似看作SQL在共享區的命中率，小於<95%,需要考慮到繫結，如果低於80%，那麼就可能SQL基本沒有被重用。

Execute to Parse %  ：   SQL語句執行與解析的比率。如果某條新的SQL語句經過一次解析然後執行，且再也不在同一個session中執行的話，那麼比率為0，這個比率應該越高越好。比如這裡的36.04%說明， 同一個session中執行的SQL語句中只有36.04%的SQL是已經解析好了的(不需要再次解析)。 說明DB中新的SQL語句相對較多。

Execute to parse＝round(100 * (1-Parses/Executions),2),   如果parse次數大於executions，可能會導致此值為負數，對效能會有影響 。 這個值越接近100%越好 (即Parses/Executions 越接近0，也即幾乎所有SQL都是已經解析過的，只要執行就好了)。

Latch Hit %：   每次申請一個latch的時候，成功的機率有多少。如果低於99%, 則說明有latch競爭問題。 要確保>99%，否則存在嚴重的效能問題， 比如繫結變數使用，熱點塊分散，共享池調整(過小) 等。

Parse CPU to Parse Elapsd %：

計算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實際執行時間/(解析實際執行時間+解析中等待資源時間)。此處為89.28%，用於解析花費的每個CPU秒花費了大約1/0.8928=1.12秒的wall clock（掛鐘）時間， 這說明花了0.12秒時間等待一個資源。如果該比率為100%，意味著CPU時間等於經過的時間，沒有任何等待。值越大，說明消耗在等待資源上的時間越少。

% Non-Parse CPU：     計算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗時間過多。這個比值越接近100% 越好，說明資料庫大部分時間是花在執行SQL語句上，而不是解析SQL語句。 

Memory Usage%   :   表示被使用的部分佔shared pool總大小的百分比，如果太低，浪費記憶體，如果值太高，說明利用率過大，可能因為shared pool中物件被經常重新整理出記憶體，導致SQL語句硬解析增加。這個數字應該長時間穩定在75%～90% 。

 %SQL with executions>1 :  表示shared pool中執行次數大於1次的SQL語句佔SQL語句總數比例是94.48%。

 %Memory for SQL w/exec>1 :    這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗的記憶體佔shared pool的百分比。這個數字將在總體上與% SQL with executions>1非常接近，除非有某些查詢任務消耗的記憶體沒有規律。 在穩定狀態下，總體上會看見隨著時間的推移大約有75%～85%的共享池被使用。如果報表的時間視窗足夠大到覆蓋所有的週期，執行次數大於一次的SQL語句的百分率應該接近於100%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。

Top 5 Timed Events 中如果是空閒等待時間，可以無需關注，我們只需要關心非空閒等待事件。  常見的空閒事件有: 

dispatcher timer

　　 lock element cleanup

　　 Null event

　　 parallel query dequeue wait

　　 parallel query idle wait - Slaves

　　 pipe get

　　 PL/SQL lock timer

　　 pmon timer- pmon

　　 rdbms ipc message

　　 slave wait

　　 smon timer

　　 SQL*Net break/reset to client

　　 SQL*Net message from client

　　 SQL*Net message to client

　　 SQL*Net more data to client

　　 virtual circuit status

　　 client message

 

Top 5 Timed Events 中列出的等待事件不一定是當時列出的5項，每次收集都會變化，

這裡列出經常出現的一些事件做簡單分析。  注意在Oracle 9.2 以前這個專案叫做Top 5 Wait Events， 在9.2及之後版本才更改為 Top 5 Timed Events， 且包含”CPU time” 其中的Waits 表示等待次數，Time(s)表示等待時間(秒)，一般主要看等待時間。 Avg Wait (ms) 表示平均每次等待的時間， % Total Call Time 表示該等待事件在總的呼叫時間裡的百分比是多少， Wait Class表示等待的級別。

 

CPU time    :     CPU time其實不是真正的等待事件。是衡量CPU是否瓶頸的一個重要指標, 

Elapsed Time = CPU Time + Wait Time 。  一般來講，一個良好的系統，CPU TIME 應該排在TOP 5 TIME Event的最前面，否則，就要進行調整以減少其他的WAIT TIME。 當然這也是相對的， 如果不存在顯著的 latch wait 或過高的logical read  等,  CPU time 佔的比例高才是令人放心的。 也就是說CPU在高效率幹活是好事，但是是否因為低效的設定或SQL而消耗CPU時間就需要注意了。  

 

db file sequential read 與 db file scattered read.   

這兩個事件是出現比較頻繁的事件。 他們表明Oracle核心請求從磁碟讀取資料塊 (到buffer cache中), 他們的區別就是

sequential 是單塊讀（序列讀），而scattered 表示多塊讀。(和是否全表掃描無關, 只是全表掃描一般表現為多塊讀) 。 這兩個事件描述的是如何將資料塊儲存到記憶體中的, 而不是如何從磁碟進行讀取。

  

db file scattered read 

一次獲取的block被分散在buffer的不連續空間中，通常表示全表掃描過多，可檢查應用程式是否合理的使用了索引，資料庫是否合理的建立了索引 。 db file scattered read是用來表示順序讀取(例如,全表掃描)。

db file sequential read 
通常暗示著透過索引獲取資料量比較大（比如透過索引進行範圍掃描獲取表資料百分比過大或者錯誤的使用索引），多表連線的時候連線順序不當，hash join時hash_area_size無法容納hash table 等。db file sequential read是用來表示隨機讀取(例如,索引掃描)。

 

深入解析db file sequential read 及 db file scattered read ：

 定義

事件名db file sequential read與db file scattered read描述的是如何將資料塊儲存到記憶體中的,而不是如何從磁碟進行讀取. 如果填充磁碟讀取的內容的記憶體是連續的, 發生的磁碟讀就是db file sequential read ,  當填充從磁碟讀取的資料的記憶體的連續性無法被保證的時候,發生的磁碟讀就是db file scattered read. 

 

db file sequential read 

Oracle 為所有的單塊讀取生成db file sequential read事件（既然是單個，當然是連續的，你可以發現db file sequential read 等待事件的P3引數一般都是1）. Oracle始終將單個資料塊儲存在單個快取塊(cache buffer)中,  因此單塊讀取永遠不會產生db file scattered read事件.  對於索引塊，如果不是快速全索引掃描，一般都是一個一個塊讀取的，所以說，這個等待事件很多時候都是索引讀取引起的。 

這一事件通常顯示與單個資料塊相關的讀取操作(如索引讀取)。如果這個等待事件比較顯著，可能表示在多表連線中，表的連線順序存在問題，可能沒有正確的使用驅動表; 或者可能說明不加選擇地進行索引。 在大多數情況下我們說，透過索引可以更為快速的獲取記錄，所以對於一個編碼規範、調整良好的資料庫，這個等待很大是很正常的。但是在很多情況下，使用索引並不是最佳的選擇，比如讀取較大表中大量的資料，全表掃描可能會明顯快於索引掃描，所以在開發中我們就應該注意，對於這樣的查詢應該進行避免使用索引掃描。

db file scattered read  

db file scattered read 一般都是等待同時讀取多個塊到記憶體中。為了效能和更有效的記憶體空間利用，oracle一般會把這些塊分散在記憶體中。db file scattered read 等待事件的P3引數指出了每次I/O讀取的塊數。每次I/O讀取多少個塊， 由引數db_file_multiblock_read_count控制。 全表掃描或者快速全索引掃描時一般使用的這種讀取塊的方式，所以，該等待很多時候都是因為全表掃描引起的 ；在大部分情況下, 全表掃描與快速全索引掃描都會產生一次或多次db file scattered read. 不過, 有時 , 這些掃描只會產生db file sequential read.  

因為全表掃描被置於LRU（Least Recently Used，最近最少使用）列表的冷端（cold end），對於頻繁訪問的較小的資料表，可以選擇把他們Cache到記憶體中，以避免反覆讀取。當這個等待事件比較顯著時，可以結合v$session_longops 以及動態效能檢視來進行診斷，該檢視中記錄了長時間（執行時間超過6秒的）執行的事物，可能很多是全表掃描操作（不管怎樣，這部分資訊都是值得我們注意的）。 

 

latch free 

latch是一種輕量級的鎖。一般來說，latch由三種記憶體元素組成：pid（程式id），記憶體地址和記憶體長度。Latch保證對共享資料結構的排它性訪問，以此來保證記憶體結構的完整性不受到損壞。在多個會話同時修改或者檢視(inspect)sga中同一個記憶體結構時，必須序列化訪問以保證sga中資料結構的完整性。 

Latch只是用來保護sga中的記憶體結構。對資料庫中的物件的保護，使用的lock而不是latch。Oracle sga中有許多latch，用來保護sga中各種記憶體結構不會因為併發訪問而損壞。常見的Latch Free等待事件是由於熱塊 (buffer cache中的latch爭用) 及未使用繫結變數(shared pool中的latch爭用) 導致的。

 最常見的Latch集中於Buffer Cache的競爭和Shared Pool的競爭。和Buffer Cache相關的主要Latch競爭有cache buffers chains和cache buffers lru chain，和Shared Pool相關的主要Latch競爭有Shared Pool Latch和Library Cache Latch等。  Buffer Cache的Latch競爭經常是由於熱點塊競爭或低效的SQL語句引起； Shared Pool的Latch競爭通常是由於SQL的硬解析引起。過大的共享池可能導致shared pool latch 爭用(9i之前的版本)；

當latch在系統範圍內的等待時間比較顯著時，你可以透過v$latch中的sleeps列來發現爭用顯著的latch：

Select  name,  gets,  misses, immediate_gets,  immediate_misses,  sleeps
from   v$latch  order  by sleeps  desc  ;    

 

buffer busy waits 

發生條件：

block正被讀入緩衝區或者已經在緩衝區正被其他session修改, 一個會話嘗試去pin 住它，這時當前block已經被pin住，就發生了競爭，產生一個buffer busy waits, 該值不應該大於1% 。可以檢視v$waitstat 看到大概的buffer busy waits 分佈 。

解決辦法：
出現此情況通常可能透過幾種方式調整： 增大data  buffer, 增加freelist，減小pctused, 增加回滾段數目，增大initrans,  考慮使用LMT+ASSM,  確認是不是由於熱點塊造成(如果是可以用反轉索引,或者用更小塊大小)  . 

該等待事件表示正在等待一個以非共享方式使用的緩衝區，或者表示當前正在被讀入buffer cache。一般來說Buffer Busy Wait不應大於1%。     檢查緩衝等待統計部分（如下）Segments By Buffer Busy Waits (或V$WAITSTAT)，看一下等待是否位於段頭(Segment Header)。       如果是，可以考慮增加自由列表(freelist，對於Oracle8i DMT)或者增加freelist groups(在很多時候這個調整是立竿見影的， 在8.1.6及以後版本，動態修改feelists需要設定COMPATIBLE至少為8.1.6)， Oracle9i或以後可以使用ASSM .

alter table xxx storage(freelists  n); 

 

--查詢等待塊型別

SELECT   'segment Header' CLASS,         a.Segment_Type,

         a.Segment_Name,

         a.Partition_Name

  FROM   Dba_Segments a, V$session_Wait b

 WHERE       a.Header_File = b.P1

         AND a.Header_Block = b.P2

         AND b.Event = 'buffer busy waits'

UNION

SELECT   'freelist Groups' CLASS,

         a.Segment_Type,

         a.Segment_Name,

         a.Partition_Name

  FROM   Dba_Segments a, V$session_Wait b

 WHERE   b.P2 BETWEEN a.Header_Block + 1

                  AND  (a.Header_Block + a.Freelist_Groups)

         AND a.Header_File = b.P1

         AND a.Freelist_Groups > 1

         AND b.Event = 'buffer busy waits'

UNION

SELECT   a.Segment_Type || ' Block' CLASS,

         a.Segment_Type,

         a.Segment_Name,

         a.Partition_Name

  FROM   Dba_Extents a, V$session_Wait b

 WHERE       b.P2 BETWEEN a.Block_Id AND a.Block_Id + a.Blocks - 1

         AND a.File_Id = b.P1

         AND b.Event = 'buffer busy waits'

         AND NOT EXISTS (SELECT   1

                           FROM   Dba_Segments

                          WHERE   Header_File = b.P1 AND Header_Block = b.P2);

 

對於不同的等待塊型別，我們採取不同的處理辦法：

 1.data segment header：
程式經常性的訪問data segment header通常有兩個原因：獲取或修改process freelists資訊;  擴充套件高水位標記。    針對第一種情況，程式頻繁訪問process freelists資訊導致freelist爭用，我們可以增大相應的segment物件的儲存引數freelist或者freelist groups；若由於資料塊頻繁進出freelist而導致程式經常要修改freelist，則可以將pctfree值和pctused值設定較大的差距，從而避免資料塊頻繁進出freelist；  對於第二種情況，由於該segment空間消耗很快，而設定的next extent過小，導致頻繁擴充套件高水位標記，解決的辦法是增大segment物件的儲存引數next extent或者直接在建立表空間的時候設定extent size uniform. 。 

2.data block：
某一或某些資料塊被多個程式同時讀寫，成為熱點塊，可以透過如下辦法來解決這個問題：
(1) 降低程式的併發度，如果程式中使用了parallel查詢，降低parallel degree，以免多個parallel slave同時訪問同樣的資料物件而形成等待降低效能
(2) 調整應用程式使之能讀取較少的資料塊就能獲取所需的資料，減少buffer gets和physical reads
(3) 減少同一個block中的記錄數，使記錄分佈於更多的資料塊中，這可以透過若干途徑實現：可以調整segment物件的pctfree值，可以將segment重建到block size較小的表空間中，還可以用alter table minimize records_per_block語句減少每塊中的記錄數
(4) 若熱點塊物件是類似自增id欄位的索引，則可以將索引轉換為反轉索引，打散資料分佈，分散熱點塊 ； 如果等待處於索引塊，應該考慮重建索引、分割索引或使用反向鍵索引。

 

對於多事務併發訪問的資料表，關於ITL的競爭和等待可能出現，為了減少這個等待，可以增加initrans，使用多個ITL槽.  

3.undo segment header：
undo segment header爭用是因為系統中undo segment不夠，需要增加足夠的undo segment，根據undo segment的管理方法，若是手工管理模式，需要修改rollback_segments初始化引數來增加rollback segment， 若是自動管理模式，可以減小transactions_per_rollback_segment初始化引數的值來使oracle自動增多rollback segment的數量

4.undo block：
undo block爭用是由於應用程式中存在對資料的讀和寫同時進行（需要適當減少大規模的一致性讀取），讀程式需要到undo segment中去獲得一致性資料，解決辦法是錯開應用程式修改資料和大量查詢資料的時間 ASSM 結合LMT 徹底改變了Oracle 的儲存機制，點陣圖freelist 能夠減輕緩衝區忙等待(buffer busy wait)，這個問題在Oracle9i 以前的版本里曾是一個嚴重的問題。

　　Oracle 宣稱ASSM 顯著地提高了DML 併發操作的效能，因為(同一個)點陣圖的不同部分可以被同時使用，這樣就消除了尋找剩餘空間的序列化。根據Oracle 的測試結果，使用點陣圖會消除所有分段頭部(對資源)的爭奪，還能獲得非常快的併發插入操作。在Oracle9i或以後版本之中，Buffer Busy wait 不再常見。

 

Free buffer waits 

表示data buffer裡沒有空閒可用buffer，使得當前會話程式處於Free buffer wiats等待狀態， Free buffer waits的等待原因一

般有以下幾個：
-  DATA BUFFER太小；
-  DBWR程式寫的效率比較低；
-  LGWR寫的太慢，導致DBWR等待；
-  正在把大量髒塊寫入到磁碟；
-  SQL語句效率低，需對Top SQL進行最佳化。

 enqueue 

佇列競爭： enqueue是一種保護共享資源的鎖定機制。該鎖定機制保護共享資源，如記錄中的資料，以避免兩個人在同一時間更新同一資料。Enqueue 包括一個排隊機制，即FIFO（先進先出）排隊機制。  Enqueue等待常見的有ST、HW 、TX 、TM等 

 ST enqueue，用於空間管理和字典管理的表空間(DMT)的區間分配，在DMT中典型的是對於uet$和fet$資料字典表的 爭用。對於支援LMT的版本，應該儘量使用本地管理表空間. 或者考慮手工預分配一定數量的區(Extent)，減少動態擴充套件時發生的嚴重佇列競爭。

HW enqueue指和段的高水位標記相關等待；手動分配適當區可以避免這一等待。

TX鎖（事務鎖）是最常見的enqueue等待。TX enqueue等待通常是以下三個問題之一產生的結果。
第一個問題是唯一索引中的重複索引，你需要執行提交（commit）/回滾（rollback）操作來釋放enqueue。
第二個問題是對同一點陣圖索引段的多次更新。因為單個點陣圖段可能包含多個行地址（rowid），所以當多個使用者試圖更新同一段時，可能一個使用者會鎖定其他使用者請求的記錄，這時等待出現。直到獲得鎖定的使用者提交或回滾， enqueue釋放。 第三個問題，也是最可能發生的問題， 多個使用者同時更新同一個塊。如果沒有足夠的ITL槽，就會發生塊級鎖定。透過增大initrans和/或maxtrans以允許使用多個ITL槽（對於頻繁併發進行DML操作的資料表，在建表之初就應該考慮為相應引數設定合理的數值，避免系統執行以後線上的更改，在8i之前，freelists等引數不能線上更改，設計時的考慮就尤為重要），或者增大表上的pctfree值，就可以很容易的避免這種情況。

 

TM enqueue佇列鎖在進行DML操作前獲得，以阻止對正在操作的資料表進行任何DDL操作(在DML操作一個資料表時，其結構不能被更改)。

log file parallel write  /  log file sync (日誌檔案同步)

如果你的Log group 存在多個組成員，當flush log buffer 時，寫操作是並行的，這時候此等待事件可能出現。 

觸發LGWR程式的條件有：
  1. 使用者提交
  2. 有1/3重做日誌緩衝區滿 
  3. 有大於1M的重做日誌緩衝區未被寫入磁碟
  4. 3秒超時
  5. DBWR 需要寫入的資料的SCN大於LGWR記錄的SCN，DBWR 觸發LGWR寫入。

 

當一個使用者提交(commits)或者回滾(rollback),session的redo資訊需要寫出到redo logfile中.使用者程式將通知LGWR執行寫出操作,LGWR完成任務以後會通知使用者程式.  這個等待事件就是指使用者程式等待LGWR的寫完成通知.    對於回滾操作，該事件記錄從使用者發出rollback命令到回滾完成的時間.

如果該等待過多，可能說明LGWR的寫出效率低下，或者系統提交過於頻繁.  針對該問題，可以關注:  log file parallel write等待事件 。  user commits,user rollback等統計資訊可以用於觀察提交或回滾次數 

 

解決方案： 
1.提高LGWR效能：儘量使用快速磁碟，不要把redo log file存放在raid 5的磁碟上
2.使用批次提交
3.適當使用NOLOGGING/UNRECOVERABLE等選項

可以透過如下公式計算平均redo寫大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes 

如果系統產生redo很多，而每次寫的較少，一般說明LGWR被過於頻繁的啟用了.
可能導致過多的redo相關latch的競爭。  

 

下面的等待事件與RAC有關(節點間資源爭用)：

gc current block busy  ：

gcs log flush sync  ：

gc buffer busy ： 熱點塊問題；節點隔離/業務隔離以減少節點間的資源爭用；

 

 

Log File Switch

當這個等待出現時，表示所有的提交(commit)的請求都需要等待"日誌檔案切換"的完成。這個等待事件出現時通常是因為日誌組迴圈寫滿以後，第一個日誌歸檔尚未完成，出現該等待。出現該等待，可能表示io 存在問題。

解決辦法:

　　可以考慮增大日誌檔案和增加日誌組

　　移動歸檔檔案到快速磁碟

　　調整log_archive_max_processes .

　　log file switch (checkpoint incomplete)-日誌切換(檢查點未完成)

　　該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。

         需要考慮增加額外的DBWR 或者增加你的日誌組或日誌檔案大小。

 

control file sequential read / control file parallel write

如果等待時間比較長，非常明顯， 需要考慮改善控制檔案所在磁碟I/O .

 

 

SQL Statistics 按照不同指標排序統計的資料非常有用，結合所有的統計資訊，可以

找出執行效能差的SQL語句，以及執行不合理(比如執行次數非常多)的SQL .  比較容易看懂，這裡不詳細介紹。 

 

 

上面的很多項都比較好理解，這裡簡單說一下下面的幾個：

  SQL ordered by Parse Calls : 什麼是parse calls 請參考（包括硬解析，軟解析，及softer解析）：  

http://space.itpub.net/35489/viewspace-697499

  

SQL ordered by Version Count :   包含版本較多的sql語句，即parent cursors相同，而children cursors不同的sql語句。  即，SQL文字一模一樣，父親遊標可以共享，但是因為最佳化器環境設定不同( OPTIMIZER_MISMATCH)，  繫結變數的值的長度在第二次執行的時候發生顯著的變化(BIND_MISMATCH) , 授權關係不匹配(AUTH_CHECK_MISMATCH ) 或者 基礎物件轉換不匹配(TRANSLATION_MISMATCH) 等導致子游標不能共享，需要新生成一個子遊標 。 這與SQL共享 (即遊標共享) 是有關係的 。 這種情況下的執行計劃可能不同，也可能相同(我們可以透過plan_hash_value看出);   具體的mismatch可以查詢 V$SQL_SHARED_CURSOR

 Advisory Statistics

 除了透過此項檢視相關建議之外。 還可以透過如下的檢視查詢。

GV_$DB_CACHE_ADVICE
GV_$MTTR_TARGET_ADVICE
GV_$PGATARGET_ADVICE_HISTOGRAM
GV_$PGA_TARGET_ADVICE
GV_$SHARED_POOL_ADVICE
V_$DB_CACHE_ADVICE
V_$MTTR_TARGET_ADVICE
V_$PGA_TARGET_ADVICE
V_$PGA_TARGET_ADVICE_HISTOGRAM
V_$SHARED_POOL_ADVICE

 

Buffer Pool Advisory  /  PGA Memory Advisory  / SGA Target Advisory / 。。。。。。

 

 Wait Statistics

說明buffer wait 是什麼樣的等待塊型別（參考前面的buffer wait 說明及改善方法）。 

Segment Statistics ：

    * Segments by Logical Reads

    * Segments by Physical Reads

    * Segments by Row Lock Waits

    * Segments by ITL Waits

    * Segments by Buffer Busy Waits

    * Segments by Global Cache Buffer Busy

    * Segments by CR Blocks Received

    * Segments by Current Blocks Received

 

........