--AWR報告
一、第一部分--數據庫基本信息
1.快照窗口的持續時間
2.報告開始和結束的會話數量--在報告期間負載的恆定的、增加的還是減少的？
二、第二部分--負載信息
1.logical reads:邏輯讀
2.block changes:塊更改
3.physical reads：物理讀
4.physical writes:物理寫
5.user calls :用戶調用
6.parses：解析
7.hard parses:硬解析
8.W/A MB processed:工作區域處理---排序操作
****調查數據緩存區是否被正確使用，是否需要添加數據塊緩沖區大小****
1.buffer nowait --緩沖區無等待率
2.buffer hit --緩沖區命中率
*****庫緩存區很低，考慮增加共享池;查詢是否因為不恰當的綁定變量被使用**
3.library hit --庫緩存區
***重做無等待百分表示重做緩沖區被利用了，如果低，需要對重做日志緩沖區和重做日志進行調優***
4.redo nowait ---重做無等待
****parse CPU to parse elapsd 如果低，表示在整個解析過程中，實際在CPU上運算的時間很短，主要的解析時間都消耗在其他分空閑等待上面了***
5.execute to parse --執行解析
6.parse CPU to parse elapsd --解析CPU時間和總解析時間比
***PGA_AGGREGATE_TARGET 參數或者 手工配置時的 SORT_AREAA_SIZE,HASH_AREA_SIZE 參數，位圖設置是否需要檢查 ***
7.memory sort --內存排序---如果百分比小於100，表示排序在磁盤進行;磁盤排序是緩慢的，可能導致嚴重的性能問題
******
8.soft parse --軟解析，我們提交的SQL語句在游標緩存中找到的頻率;--硬解析會導致遞歸SQL
9.latch hit ---(shuān)閂鎖命中率---如果百分比低，需要查詢CPU受限進程和閂鎖的問題
10.非解析(non-parse)CPU百分比---CPU在處理請求時候花費的時間，--如果低，表示系統花費了很多時間在處理SQL語句，沒有足夠的時間做真正的工作
三、等待事件、CPU、內存的統計數據
****注意：在一個適當調優的系統中，CPU使用率應該占主導地位***
1.RAC環境中占主導地位的等待事件可能是與重做日志相關的，互聯相關的或者撤銷表空間相關的
2.gc current block 2-way 說明相同的塊在節點互聯中被來回共享
3.主要等待時間是 db file sequential read 表示單塊讀取(索引讀)引起的問題;--解決辦法：增加更多的DB塊緩存內存(服務器內存)
****1.通過增加磁盤陣列中磁盤的數量，使讀操作的文件更分散;2.進一步降低這個等待事件的方法是通過提升服務器的內存數量或者通過移動數據到全閃陣列來減少讀延遲
****當I/O系統壓力較大時，通常看見的另一個等待是 db file scattered read，表示發生了全表或者全索引掃描
****1.全表掃描可以通過適當的索引來糾正;2.或者可以使用分區減少掃描的數據量3.唯一解決辦法:通過大規模的緩存或者使用全閃存陣列來減少延遲
****當db file sequential read 或者db file scattered read 成為重要等待時，DBA需要查看報告的SQL部分;通常出現在兩個或者更多的SQL字句中，他就是調優操作的最佳候選對象
4.日志文件壓力(重做日志)的一個關鍵指標是log file sync;log file parallel write;log file sequential write;log file single write和log file switch completion 占top主導地位
****必須確保等待是真正的來自於I/O 相關的問題，而不是歸檔日志之類的問題
****1.通常日志文件放在數據和索引文件相同的物理磁盤上時，日志文件壓力就會出現
****2.可以將日志文件轉移到自己的磁盤陣列;或者在使用基於閃存的存儲系統時，使用單個邏輯單元號lun將日志文件從其他文件中分離出來，緩解日志文件的壓力
5. Host CPU *** load average begin/end 表示有多少個進程正在等待
6.Instance CPU 顯示 實例使用CPU 的效率有多高
7.Memory Statistics 內存使用
*** % Host Mem used for SGA+PGA: 表示使用系統多少內存
*** SGA use (MB):276,480.0 到 276,480.0 很穩定
*** PGA use (MB):1,856.4 到 1,869.1 增加了 12.7M
8.RAC 持有界面 ;在頭部和系統配置區域之后是一個RAC持有 章節
RAC Statistics
9.Time Model Statistics CPU 時間分類
****注意:如果解析時間和硬解析時間值很接近，那么就是產生了過渡的硬解析******
10.Operating System Statistics 操作系統統計信息
***空閑時間(%idle)和I/O等待事件的統計值大於繁忙(%busy)時間值
11.Foreground Wait Class 前台等待事件---前台進程是用戶或者應用程序級的進程
%DB time 時間中占用不到0.1%的等待事件可以忽略;
***RAC環境中看到大量的 read by other session 的等待事件,通常表塊太大或者延遲太大，從而導致爭用;
***如果 read by other session 是主要等待事件之一，那么看awr 報告中 segments by x 部分確認那些表和索引正在被大量使用
***可以考慮將這些段移到一個小於默認塊大小的表空間，比如4KB或者2KB，或者降低存儲延遲(IBM FlashSystem減少這種爭用)
12.Background Wait Events 后台等待事件 --Oracle進程堆棧中眾多后台進程生產的等待(DBWR LGWR SMON PMON )
*** control file sequential re 或者 control file parallel write 屬於I/O等待事件相關的等待
13.Wait Event Histogram 等待事件直方圖---基於時間的直方圖報告
***直方圖報告，根據時間名稱來排序的
***讀等待事件比寫等待事件更重要
***磁盤正在承受壓力---1通過增加磁盤陣列中的磁盤數量2.提供更大IOPS的選擇是使用IBM的閃存技術
14.Service Statistics 服務相關統計數據
***服務是一組用於提供公共功能的進程(比如:用於為同一用戶提供一系列SQL語句的所有並行查詢的子進程(slaves)和進程(processes)都可以被分到一個服務中)
***1s等於1000ms;基於磁盤的非緩存系統的最佳等待時間是5ms
15.SQL章節
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
SQL ordered by Cluster Wait Time
******SQL語句出現在以上兩個或者多個區域的TOP5語句中，那么它就是調優的主要候選對象
***15.1 如果一個SQL語句出現在報告的總運行時間(Elapsed Time)區域內，表示它的CPU時間加上其他的等待時間很高;
***如果由於某種原因，SQL處於總運行時間的頂部，而不是總CPU時間的頂部，則表明改SQL語句存在與遞歸調用有關的問題(比如:不佳的解析率);
***15.2 SQL語句出現在總CPU時間(CPU Time)部分時，則表明它在處理期間使用了過多的CPU周期
***過多的CPU處理時間可能是由:排序、過多的函數和長時間的解析造成的;
***為了減少CPU可以使用排序消除器多的多列索引來減少排序，也可以使用綁定變量來減少解析時間
******小竅門:如果SQL是大寫的，那么它可能來自於用戶或者應用程序;如果是小寫的，則通常來自內部或者后台進程;所有表字段中包含單引號的SQL通常是工具產生的******
***15.3 高總緩沖區獲取表明SQL語句從DB緩沖區中讀取了大量的信息;總緩沖區的典型特征:高邏輯讀、高緩沖區緩存命中率(當它被一個選擇性較差的索引驅動時)和高CPU使用率
***減少過渡使用緩沖區，可以使用分區和索引，並考慮SQL優化，避免過渡的表掃描
***15.4 總磁盤讀表明SQL語句從存儲中讀取了大量的數據，而不是DB塊緩沖區，過渡的存儲讀會導致性能問題
***減少過渡的存儲讀，可以使用分區和索引，並考慮SQL優化，避免過渡的全表掃描;內存充足的情況下，可以考慮增加DB緩沖區緩存
***總磁盤讀的典型特征:高物理讀、低緩存區命中率、低CPU使用率和I\O等待時間
***如果存儲讀是數據庫的一部分(在DSS或者數據倉庫,全表掃描是其系統架構的自然結果)可以考慮移動數據到全閃存陣列
***15.5 總執行次數(Executions)高總執行數表明數據庫中某些SQL是不正確的;大量執行語句通常被正確地重(chong)用,
***高執行次數和高邏輯讀/物理讀的語句是檢查的候選對象，以確保他們在只需要執行一次時不會執行多次
***如果數據庫中有過多的物理讀和邏輯讀，或過多的I/O等待時間，那么需要查看執行次數過多，且物理讀和邏輯讀高的SQL語句
***15.6 解析調用(Parse Calls)---當一個語句無論何時被用戶或者進程執行時，不管SQL語句是否在SQL池中存在，都需要進行解析
***解析可以是硬解析或軟解析
***如果Oracle在SQL池中找不到相同散列簽名的SQL，那么Oracle會使用大量的遞歸SQL和所有其他的解析包來進行硬解析;如果在SQL池中找到了SQL，
那么只需要使用最小的遞歸進行軟解析，以驗證底層對象的用戶權限;過多的解析調用通常伴隨着過多的執行
***如果使用的是不安全的綁定變量(指綁定變量在peek的過程中，因為某些原因導致CBO認為這個值對應的執行計划不是最優的，所以會對這個SQL根據不同的值生成多個
版本的執行計划，那么語句就會被重新解析)
***15.7 可共享內存 提供了被重用SQL語句的信息，以及他們所使用的共享池中內存的數量，只有使用共享內存超過1,048,576字節的語句才會在報告中顯示。
***通常較高消耗內存是由不良代碼或過渡的多表關聯的大SQL造成的----大語句會導致過渡的解析、遞歸和大量的CPU使用
***15.8 版本數 通常由多個相同模式數據庫、不安全的綁定變量或者Oracle bug 引起的;在Oracle 9I 或者10G 會有一些BUG導致不安全的綁定變量產生多個版本
***多個版本在共享池會耗盡SQL內存空間，高版本數也可能導致過渡的解析
****小竅門:將隱含參數 _sqlexec_progression_cost 的值設置高於默認的1000，可以降低易受影響版本 ***
***15.9 集群等待時間 只有在RAC系統時，集群等待事件才會出現;在這一節中，進行大量跨界點互連傳輸的SQL會被列出;
***如果數據塊太大，或每個服務器上的DB緩存都太小，或SQL使用了太多的表數據，就會出現高級別的塊傳輸
***大量更新語句也可能出現在這里，因為更新需要在很多情況下對當前塊進行塊傳輸
****高級別的全局緩存類型的等待事件表明需要在本節查找有問題的SQL***
***16 實例活動統計 (Instance Activity Statistics)