導出
關於awr報告的導出，上一篇博客已經進行過講述了。博客鏈接地址：https://www.cnblogs.com/liyasong/p/oracle_report1.html 這里就不再贅述。
各個字段的含義
awr報告的HTML報告，可以在網頁上直接打開。這里，按照每一部分介紹下awr報告的各個字段。
1.報告基本信息
這一部分，是報告的一些基本信息。分別包括：
上面部分，數據庫物理環境相關信息。
第一行，DB Name 數據庫名（數據庫名是存儲在控制文件中，代表數據庫所有物理文件的總稱）。DB Id 數據庫id（數據庫的dbid可能在數據庫文件恢復中需要用到，查詢數據庫DB Id的sql語句為：select dbId from v$database;）。Instance 實例名 （實例名（sid），寫數據庫地址的時候，192.168.*.*:1521/orcl 這里的orcl就是實例名）初始實例編號（暫時不知道干什么用的，歡迎指導）。Startup Time 數據庫啟動時間（本次導出awr報告對應時段的數據庫啟動時間）。Release 數據庫版本（不同的版本awr報告不全一樣，這里是11.2版本的數據庫）。RAC real application cluster 數據庫自己的集群系統（分布式數據庫，安裝設置好集群后，從集群的任何一個節點數據庫都可以同步到其他節點，這里沒有開啟）
第二行，HostName 服務器名（oracle所在服務器的名稱，鏈接的時候需要驗證的一個信息）。Platform 操作系統（orale的安裝環境，什么系統，多少位）。CPUs（服務器多少顆cpu）。Cores（服務器幾核）。Sockets （主板上CPU插槽個數）Memory (GB) 內存大小。
下面部分，快照信息。
| snap id 快照id |
snap time 快照時間 |
session 會話 |
Cursors/Session 游標/ 會話 |
|
| begin Snap(起始快照) | ||||
| end snap （終止快照） | ||||
| elapsed: (跨度) | ||||
| DB TIme（請求時間） |
其中，快照起始/終止時間和起始/終止Id是創建awr報告的時候自己選的。會話數量表示在這次快照采集的時間內，oracle總共有多少次會話鏈接。Cursors/Session 每個會話平均使用多少個游標（游標，一個內存工作區，臨時存儲從數據庫中提取的數據塊）。DB Time：是記錄的服務器花在數據庫運算 ( 非后台進程 ) 和等待( 非空閑等待 ) 上的時間。不包括 Oracle 后台進程消耗的時間。db time= cpu time + wait time（不包含空閑等待） （非后台進程） 這里是這樣算的：首先，有四個cpu總共耗時3.4mins 。平均每隔cpu耗時不到一分鍾。cpu利用率只有 1/360（快照采集總間隔時間） 百分之0.3不到，說明系統處於空閑狀態。這也是為什么我們要盡可能使用需要分析的時間段的快照來進行分析的原因，因為快照跨度太長，有可能會導致dbtime的指標受到影響。
2.報告簡要信息
①.cache size 緩存大小
這里粗略的展示下系統的內存使用情況。其中包括：Buffer Cache 數據高速緩沖區，存放着oracle訪問的數據塊，存滿后，自動去除最不常用的數據。通俗講，就是將高頻率使用的sql查詢結果進行緩存，提高查詢效率。Std Block Size 數據塊大小 。 Shared Pool Size 共享池 ，用來緩存被執行的sql和被使用的數據定義。包括 Library cache和Data dictionary cache ，Library cache 用來存放sql語句的文本，分析后代碼及執行計划。Data dictionary cache 緩存數據字典，存放有關表、列和其他字段及相對應的權限。Log Buffer 全名redo log buffer 緩存被執行的SQL語句和被使用的數據定義。
②.Load Profile 數據庫負載屬性信息
DB Times 請求時間 等待cpu的時間與數據庫消耗CPU時間的總和。
DB CPU 數據庫消耗cpu時間（所有用戶的累加值）
Redo size 產生日志的大小，標識數據庫的變更語句執行頻率，數據庫任務的繁忙程度。
Logical Read 邏輯讀，從（或試圖從）Buffer Cache中讀取數據塊。邏輯讀包括當前數據讀取和一致性讀取：Logical Reads= Consistent Gets + DB Block Gets 。邏輯讀受制於CPU性能，可以反映CPU使用情況。
Block changes 修改的數據塊數量，標識數據的變化頻率。
Physical Read 物理讀數據塊數量，物理讀消耗io資源。
Physical writes 物理寫數據塊數量，包括寫入數據庫+寫入緩存
User Calls 用戶調用次數
Parses 解析次數，包括 fast parse ，軟解析和硬解析。其中fast parse 是最快的，直接在PGA中命中（需要設置session_cached_cursors=n）；其次是軟解析，在shared pool中命中；都不命中，則觸發hard parse 。parses 超過300 意味着SQL解析復用效率不高。
Hard Parses 硬解析，硬解析標識SQL不命中的次數，每秒應小於20次。超過一百次，需要檢查是不是共享池（shared pool）設置的不合理。
W/A MB processed 工作區處理的任務數量 。
Logons 用戶登錄次數。並發session越高，數值越大。
Executes 標識 SQL執行次數，反映執行效率。
Rollback 回滾次數。
Transactions 事物數。每秒的事物數可以反映任務的繁重情況。
SQL解析過程：
軟解析和硬解析，Oracle對SQL的處理過程：
1.語法檢查（syntax check） 檢查SQL語法是否符合規范。
2.語義檢查（semantic check） 檢查SQL中對應的對象（表，視圖等）是否存在及該用戶是否具備相應的權限。
3.解析SQL語句 （prase） 對SQL進行解析，生成解析樹（parse tree）及執行計划（execution plan）。
4.執行SQL 返回結果集。
首先，fast prase :在設置session_cursor_cache 這個參數后，Cursor被直接Cache在當前Session的PGA中，在解析的時候對SQL進行語法分析、權限對象分析之后。先轉到PGA中查找，如果發現完全相同的SQL，直接獲取結果返回。
其次，軟解析（soft parse） 在第3步執行前，先在共享池（Shared Pool ）中找是否有相同的SQL，如果找到，直接使用該SQL解析好的解析樹和執行計划。
最后，硬解析（Hard Parse） 沒有任何緩存，直接解析SQL並運行，得到相應返回結果。
邏輯讀，物理讀
邏輯讀：指從Buffer Cache中讀取數據塊
1、及時讀：即時讀即讀取數據塊當前的最新數據。任何時候在Buffer Cache中都只有一份當前數據塊。即時讀通常發生在對數據進行修改、刪除操作時。這時，進程會給數據加上行級鎖，並且標識數據為“臟”數據。
2、數據一致性讀：Oracle是一個多用戶系統。當一個會話開始讀取數據還未結束讀取之前，可能會有其他會話修改它將要讀取的數據。如果會話讀取到修改后的數據，就會造成數據的不一致。一致性讀就是為了保證數據的一致性。在Buffer Cache中的數據塊上都會有最后一次修改數據塊時的SCN。如果一個事務需要修改數據塊中數據，會先在回滾段中保存一份修改前數據和SCN的數據塊，然后再更新Buffer Cache中的數據塊的數據及其SCN，並標識其為“臟”數據。當其他進程讀取數據塊時，會先比較數據塊上的SCN和自己的SCN。如果數據塊上的SCN小於等於進程本身的SCN，則直接讀取數據塊上的數據；如果數據塊上的SCN大於進程本身的SCN，則會從回滾段中找出修改前的數據塊讀取數據。通常，普通查詢都是一致性讀。
物理讀：數據塊是oracle最基本的讀寫單位,但用戶所需要的數據,並不是整個塊,而是塊中的行,或列.當用戶發出SQL語句時,此語句被解析執行完畢，就開始了數據的抓取階段,在此階段,服務器進程會先將行所在的數據塊從數據文件中讀入buffer cache,這個過程叫做物理讀，每讀取一個塊,就算一次物理讀。
③. Instance Efficiency Percentages (Target 100%)
上面這些所有目標都是100%，越大越好。正常情況下，值在0-100之間。
Buffer Nowat: session 在訪問一個buffer時，立即可以訪問的比率。如果低於99%說明存在內存爭用的情況。
Buffer Hit : 內存命中率。在一般數據庫中，如果此值低於80% 應該給數據庫分配更多的內存。如果命中率突然增大， 可以檢查 top buffer get SQL，查看導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查 top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索 引或者索引被刪除的。
Redo NoWait: 緩沖區獲得Buffer未等待比例。不低於90%，不太需要考慮。
In-memory Sort 內存中完成的排序比例。應大於 95%，不太需要考慮。
Library Hit : 執行計划命中率，當應用程序調用SQL或存儲過程的時候，如果在library Cache 中可以檢索到執行計划，直接執行。不存在，解析SQL並緩存。如果該值低於90% 可能需要調大共享池的內存大小。應保持在95%以上。
Soft Parse: 軟解析比例。重要解析指標。軟解析次數和總解析次數的比值，應該大於95 % 。
Execute to Parse 執行解析比 1-（parse/execute） 這里軟解析也是解析次數，軟解析依然會消耗DBTime 所以可以通過使用靜態SQL，動態綁定、session_cached_cursor、open cursors等技術減少軟解析。
Latch Hit ：數據塊內部行鎖不需要等待的比例。應大於99%。當前是因為系統中未共享SQL導致的低於該值。
Parse CPU To Parse Elapsd:該指標反映了 快照內解析CPU時間和總的解析時間的比值(Parse CPU Time/ Parse Elapsed Time)； 若該指標水平很低，那么說明在整個解析過程中 實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閑的等待事件上了(如latch:shared pool,row cache lock之類等)
Non-Parse CPU 非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU，比值越高，說明執行查詢工作的資源越多，分析查詢的資源消耗越少。
④.Shared Pool Statistics
一個大概的SQL重用及共享池內存使用。
Memory Usage 共享池內存使用率，應穩定在 75%-90%之間。如果太小，說明內存空間有浪費。如果高於90% 說明內存不足，有內存爭用的情況。
SQL with executions >1 復用的SQL占總的SQL語句的比率,如果值太小，需要優化SQL。
Memory for SQL w/exec>1 ：執行次數大於 1 的 SQL消耗內存的占比。大概值會在 75-85% 之間。
⑤。Top 5 Time Events
系統最嚴重的5個等待，正常情況下，DBCPU應該排在最前面。
Waits : 該等待事件發生的次數， 對於DB CPU此項不可用
Times : 該等待事件消耗的總計時間，單位為秒， 對於DB CPU 而言是前台進程所消耗CPU時間片的總和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 該等待事件平均等待的時間， 實際就是 Times/Waits，單位ms， 對於DB CPU此項不可用
Wait Class: 等待類型：Concurrency,System I/O,User I/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit
⑥ CPU
“Load Average” begin/end值代表每個CPU的大致運行隊列大小。
%User+%System=> 總的CPU使用率。
%Total CPU,該實例所使用的CPU占總CPU的比例
%Busy CPU，該實例所使用的Cpu占總的被使用CPU的比例
`⑦.內存使用
host mem 主機內存.
SGA use SGA 使用內存。SystemGlobal Area是OracleInstance的基本組成部分，在實例啟動時分配;系統全局域SGA主要由三部分構成：共享池、數據緩沖區、日志緩沖區。
PGA use PGA內存。ProcessGlobal Area是為每個連接到Oracledatabase的用戶進程保留的內存。
Host Mem used for SGA+PGA: 數據庫使用內存占總內存比例。