Oracle 10g AWR 報告分析

1.1.1. SQL ordered by Elapsed Time：

   記錄了執行總和時間的TOP SQL(請注意是監控範圍內該SQL的執行時間總和，而不是單次SQL執行時間 Elapsed Time = CPU Time + Wait Time)。

SQL ordered by Elapsed Time

• Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
• % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

   Elapsed Time(S): SQL語句執行用總時長，此排序就是按照這個欄位進行的。注意該時間不是單個SQL跑的時間，而是監控範圍內SQL執行次數的總和時間。單位時間為秒。Elapsed Time = CPU Time + Wait Time

  CPU Time(s): 為SQL語句執行時CPU佔用時間總時長，此時間會小於等於Elapsed Time時間。單位時間為秒。

 Executions: SQL語句在監控範圍內的執行次數總計。

 Elap per Exec(s): 執行一次SQL的平均時間。單位時間為秒。

 % Total DB Time: 為SQL的Elapsed Time時間佔資料庫總時間的百分比。

 SQL ID: SQL語句的ID編號，點選之後就能導航到下邊的SQL詳細列表中，點選IE的返回可以回到當前SQL ID的地方。

 SQL Module: 顯示該SQL是用什麼方式連線到資料庫執行的，如果是用SQL*Plus或者PL/SQL連結上來的那基本上都是有人在除錯程式。一般用前臺應用連結過來執行的sql該位置為空。

 SQL Text: 簡單的sql提示，詳細的需要點選SQL ID。

1.1.2. SQL ordered by CPU Time:

 記錄了執行佔CPU時間總和時間最長的TOP SQL(請注意是監控範圍內該SQL的執行佔CPU時間總和，而不是單次SQL執行時間)。

1.1.3. SQL ordered by Gets:

 記錄了執行佔總buffer gets(邏輯IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔Gets總和，而不是單次SQL執行所佔的Gets).

1.1.4. SQL ordered by Reads:

記錄了執行佔總磁碟物理讀(物理IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔磁碟物理讀總和，而不是單次SQL執行所佔的磁碟物理讀)。

1.1.5. SQL ordered by Executions:

 記錄了按照SQL的執行次數排序的TOP SQL。該排序可以看出監控範圍內的SQL執行次數。

1.1.6. SQL ordered by Parse Calls:

 記錄了SQL的軟解析次數的TOP SQL。

 說到軟解析(soft prase)和硬解析(hard prase)，就不能不說一下Oracle對sql的處理過程。當你發出一條sql語句交付Oracle，在執行和獲取結果前，Oracle對此sql將進行幾個步驟的處理過程：

　　1、語法檢查(syntax check)

　　檢查此sql的拼寫是否語法。

　　2、語義檢查(semantic check)

　　諸如檢查sql語句中的訪問物件是否存在及該使用者是否具備相應的許可權。

　　3、對sql語句進行解析(prase)

　　利用內部演算法對sql進行解析，生成解析樹(parse tree)及執行計劃(execution plan)。

　　4、執行sql，返回結果(execute and return)

　　其中，軟、硬解析就發生在第三個過程裡。

　　Oracle利用內部的hash演算法來取得該sql的hash值，然後在library cache裡查詢是否存在該hash值；

　　假設存在，則將此sql與cache中的進行比較；

　　假設“相同”，就將利用已有的解析樹與執行計劃，而省略了最佳化器的相關工作。這也就是軟解析的過程。

　　誠然，如果上面的2個假設中任有一個不成立，那麼最佳化器都將進行建立解析樹、生成執行計劃的動作。這個過程就叫硬解析。

　　建立解析樹、生成執行計劃對於sql的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，儘量使用軟解析。這就是在很多專案中，倡導開發設計人員對功能相同的程式碼要努力保持程式碼的一致性，以及要在程式中多使用繫結變數的原因。

/****************************************************/

大家都在說在Sql中使用了Bind Var（繫結變數）會提高不少效能，那他到底是如何提高效能的呢？

使用了Bind Var能提高效能主要是因為這樣做可以儘量避免不必要的硬分析（Hard Parse）而節約了時間，同時節約了大量的CPU資源。

當一個Client提交一條Sql給Oracle後，Oracle首先會對其進行解析（Parse），然後將解析結果提交給最佳化器（Optimiser）來進行最佳化而取得Oracle認為的最優的Query Plan，然後再按照這個最優的Plan來執行這個Sql語句（當然在這之中如果只需要軟解析的話會少部分步驟）。

但是，當Oracle接到Client提交的Sql後會首先在共享池（Shared Pool）裡面去查詢是否有之前已經解析好的與剛接到的這一個Sql完全相同的Sql（注意這裡說的是完全相同，既要求語句上的字元級別的完全相同，又要求涉及的物件也必須完全相同）。當發現有相同的以後解析器就不再對新的Sql在此解析而直接用之前解析好的結果了。這裡就節約瞭解析時間以及解析時候消耗的CPU資源。尤其是在OLTP中執行著的大量的短小Sql，效果就會比較明顯了。因為一條兩條Sql的時間可能不會有多少感覺，但是當量大了以後就會有比較明顯的感覺了。

上面說到了硬解析（Hard Parse），那這個Hard Parse到底是個啥呢？

Parse主要分為三種：

1、Hard Parse （硬解析）

2、Soft Parse （軟解析）

3、Soft Soft Parse（好像有些資料中並沒有將這個算在其中）

Hard Parse就是上面提到的對提交的Sql完全重新從頭進行解析（當在Shared Pool中找不到時候將會進行此操作），總共有一下5個執行步驟：

1：語法分析

2：許可權與物件檢查

3：在共享池中檢查是否有完全相同的之前完全解析好的—如果存在,直接跳過4和5,執行Sql（此時算soft parse）

4：選擇執行計劃

5：產生執行計劃

Soft Parse就如果是在Shared Pool中找到了與之完全相同的Sql解析好的結果後會跳過Hard Parse中的後面的兩個步驟。

Soft Soft Parse實際上是當設定了session_cursor_cache這個引數之後，Cursor被直接Cache在當前Session的PGA中的，在解析的時候只需要對其語法分析、許可權物件分析之後就可以轉到PGA中查詢了，如果發現完全相同的Cursor，就可以直接去取結果了，也就就是實現了Soft Soft Parse。

不過在計算解析次數的時候是隻計算Hard Parse和Soft Parse的（其實Soft Soft Parse好像也並不能算是做了Parse ）：

Soft Parse百分比計算：Round(100*(1-:hprs/:prse),2) [hprs：硬解析次數；prse：解析次數]

Parse比率計算： Round(100*(1-prse/exec) ,2) [exec：執行次數]

   軟解析過多的意思就是說session_cursor_cache的數值有可能小了，一些頻繁呼叫的SQL在Cache中找不到相同的Cursor。

1.1.7. SQL ordered by Sharable Memory:

 記錄了SQL佔用library cache的大小的TOP SQL。

Sharable Mem (b)：佔用library cache的大小。單位是byte。

1.1.8. SQL ordered by Version Count:

 記錄了SQL的開啟子游標的TOP SQL。

 在硬解析的過程中，程式會一直持有library cach latch，直到硬解析結束。硬解析結束以後，會為該SQL產生兩個遊標，一個是父遊標，另一個是子游標。父遊標裡主要包含兩種資訊：SQL文字以及最佳化目標（optimizer goal）。父遊標在第一次開啟時被鎖定，直到其他所有的session都關閉該遊標後才被解鎖。當父遊標被鎖定的時候是不能被交換出library cache的，只有在解鎖以後才能被交換出library cache，這時該父遊標對應的所有子游標也被交換出library cache。子游標包括遊標所有的資訊，比如具體的執行計劃、繫結變數等。子游標隨時可以被交換出library cache，當子游標被交換出library cache時，oracle可以利用父遊標的資訊重新構建出一個子遊標來，這個過程叫reload。可以使用下面的方式來確定reload的比率：
SELECT 100*sum(reloads)/sum(pins) Reload_Ratio FROM v$librarycache;
一個父遊標可以對應多個子遊標。子游標具體的個數可以從v$sqlarea的version_count欄位體現出來。而每個具體的子游標則全都在v$sql裡體現。當具體的繫結變數的值與上次的繫結變數的值有較大差異（比如上次執行的繫結變數的值的長度是6位，而這次執行的繫結變數的值的長度是200位）時或者當SQL語句完全相同，但是所引用的物件屬於不同的schema時，都會建立一個新的子游標

1.1.9. SQL ordered by Cluster Wait Time:

 記錄了叢集的等待時間的TOP SQL

1.2. 其他管理員相關問題解析：

1.2.1. Load Profile

% Blocks changed per Read:

0.85

Recursive Call %:

95.92

Rollback per transaction %:

30.79