一.AWR的概念
Oracle數據庫是一個使用量很多的數據庫，關於Oracle數據庫的性能。Oracle10g以后，Oracle提供了一個性能檢測的工具：AWR（Automatic Workload Repository 自動工作負載庫）這個工具可以自動采集Oracle運行中的負載信息，並生成與性能相關的統計數據。我們可以根據這些統計數據來分析一些潛在的問題。
二.AWR的原理
Oracle啟動后，后台會有個進程去每小時采集一次系統的快照信息，信息采集來源為： V$active_Session_History視圖。該視圖可以展示最近活動會話的歷史記錄。並將采集到的信息保存8天。（查詢SQL：select * from dba_hist_wr_control;）采樣頻率和保存時間可配置。
快照由MMON和MMNL的進程自動地每隔固定時間采集一次。MMON進程負責執行多種和管理相關的后台任務，MMNL負責執行輕量級切高頻率的管理相關的后台任務。
三.導出awr報告
oracle 可以將8天的awr快照數據進行儲存，我們可以將oracle中的任何兩個時間點（輸入日期后，會返回相應的時段內，快照對應的時間）生成該段時間內的awr報告。具體生成方式有多種，一般需要sys權限，如果讀者有更好的方法，歡迎討論。
1.首先登陸sys用戶下 sqlplus as sysdba;
然后，再新彈出的窗口中輸入@?/rdbms/admin/awrrpt.sql
按照提示，輸入導出腳本的類型（HTML還是text），輸入HTML
這里輸入的是返回幾天的快照，這里輸入1天，表示返回一天的記錄
這里返回的是范圍內的所有快照的信息。通過輸入兩個快照id生成兩個快照點之間的報告信息。這里可以根據需要進行選擇，比如說，四點的時候，系統出現了明顯的卡頓，想要分析這個卡頓出現的原因，那么最好取三點到五點之間的日志，也就是對應的26和28 兩個snapId的值。
從上圖可以看出，id為21和22之間服務器進行了重啟，不能選擇這樣的快照區間，不然會拋出異常。
這里，我們選擇12點到18點之間的日志。
然后，輸入返回awr對象的名稱，建議寫一些有代表意義的名稱，便於以后查看。
然后就是一通滾屏，最后可以看到輸出成功的提示：
導出的awr報告：
四.分析查看AWK報告
查看數據庫運行的總體情況：
從圖中可以看出：
- 這是一個雙節點的rac中的一個節點的AWR報告。
- 數據庫版本為：11.1.0.7.0
- 平台為Windows X86 64
- 有8顆CPU共16個核心數
- 一小時內產生了兩份快照
- 一小時內DB Time為174
- 所以，可以計算出這個快照周期內數據庫負載為：174/(60*16)=18%。說明此時間段內數據庫的負載是很低的。但是要注意一點，由於AWR報告展示的一段時間內的統計數據，如果快照跨度包括了大量的空閑時間，那么計算出來的CPU平均利用率也會偏低。
- 圖中10點產生快照時候，數據庫中有166個session；等到11點時數據庫中有181個session
*查看負載分析表：*
建議重點關注以下數據項：
Redo size： *Redo size* *單位* *bytes**，**redo size**可以用來估量**update/insert/delete**的頻率，大的**redo size**往往對**lgwr**寫日志，和**arch**歸檔造成**I/O**壓力。*
如何解決每秒鍾產生大量redo****？
- 增加redo log****的size
- 增加redo log****組
- 增加redo buffer
Logical reads、Block changes、Physical reads、Physical writes：，評估數據庫的讀/寫繁忙程度，判斷數據庫的活動性質和規模。
邏輯讀的單位是塊，表中每秒讀了50290.4塊，那么大小就是50290.4*8K=393M；邏輯讀影響全表掃描。
Parses、Hard parses：SQL軟解析以及硬解析的次數，評估SQL是否需要優化。
Executes、Transactions：每秒/每事務SQL執行次數、每秒事務數.每秒產生的事務數，反映數據庫任務繁重與否。
Recursive Call：遞歸調用占所有操作的比率.遞歸調用的百分比，如果有很多PL/SQL，那么這個值就會比較高。
Rollback：每秒回滾率及每事物回滾率，因為回滾很耗資源，如果回滾率過高，可能說明你的數據庫經歷了太多的無效操作 ,過多的回滾可能還會帶來Undo Block的競爭。
*查看實例效率分析報表*：
Instance Efficiency Percentages報表顯示了Oracle關鍵指標的內存命中率及其它數據庫實例操作的效率:
Buffer Nowait %：在內存獲得數據的未等待比例。這個值一般需要大於99%，否則可能存在爭用。
Buffer Hit %：數據塊在數據緩沖區中的命中率，通常應在95%以上。否則需要調整重要的參數，或者要加大db_cache_size。
Library Hit %：SQL在共享區的命中率，通常應該在95%以上。
Soft Parse %：軟解析的百分比，通常應該在95%以上。，
Execute to Parse %：語句執行與分析的比例，反映SQL的重用率。
*查看共享池統計報表*：
*Shared Pool Statistics*
Memory Usage %：共享池內存使用率，正常應在75%~90%之間，過低說明有浪費，過高則說明有爭用。
% SQL with executions>1：執行次數大於1的SQL的比例。
% Memory for SQL w/exec>1：執行次數大於1的SQL消耗內存的占比。
*查看系統Top10等待*
*一個性能良好的系統，DB CPU項應該排在前5之內*
*查看SQL統計信息*：
建議重點關注以下：
SQL ordered by Elapsed Time：記錄了執行總時間最長的Top SQL，其中Elapsed Time = CPU Time + Wait Time
SQL ordered by CPU Time：記錄了占CPU時間最長的Top SQL
SQL ordered by User I/O Wait Time：記錄了執行過程中等待IO時間最長的Top SQL
SQL ordered by Gets：記錄了執行最多邏輯讀（邏輯IO）的Top SQL
SQL ordered by Reads：記錄了執行最多物理讀（物理IO）的Top SQL
SQL ordered by Executions：記錄了執行次數最多的Top SQL，即使單條SQL****運行速度飛快，任何被執行幾百萬次的操作都將耗用大量的時間。
SQL ordered by Parse Calls****：記錄了軟解析次數最多的Top SQL
*查看Undo資源信息*：
Undo Statistics部分記錄了回滾相關的信息：
*查看行鎖等待信息*：
Segments by Row Lock Waits表展示了行鎖等待信息：
當一個進程在正被其它進程鎖住的數據行上獲得排它鎖時會發生等待，這種等待經常是由在一個有主鍵索引的表上做大量INSERT操作時引起。
五.查詢數據庫的alert
select * from v$diag_info;
VALUE
--------------------------------------------------------------------------------
1 Diag Trace
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
1 Diag Alert #數據庫文件目錄
/u01/app/oracle/diag/rdbms/orcl/orcl/alert
進入數據庫alert 及trace目錄，備份及清理
cd 進去
alert 下是log.xml 文件
注：轉載自：https://www.cnblogs.com/liyasong