* 定義：awr報告是oracle 10g下提供的一種效能收集和分析工具，它能提供乙個時間段內整個系統資源使用情況的報告，通過這個報告，我們就可以了解乙個系統的整個運**況，這就像乙個人全面的體檢報告。
如何分析：
* 在看awr報告的時候，我們並不需要知道所有效能指標的含義，就可以判斷出問題的所在，這些效能指標其實代表了oracle內部實現，對oracle理解的越深，在看awr報告的時候，對資料庫效能的判斷也會越準確
* 在看效能指標的時候，心裡先要明白，資料庫出現效能問題，一般都在三個地方，io，記憶體，cpu，這三個又是息息相關的（ps：我們先假設這個三個地方都沒有物理上的故障），當io負載增大時，肯定需要更多的記憶體來存放，同時也需要cpu花費更多的時間來過濾這些資料，相反，cpu時間花費多的話，有可能是解析sql語句，也可能是過濾太多的資料，到不一定是和io或記憶體有關係了
* 當我們把一條sql送到資料庫去執行的時候，我們要知道，什麼時候用到cpu，什麼時候用到記憶體，什麼時候用到io
1. cpu：解析sql語句，嘗試多個執行計畫，最後生成乙個資料庫認為是比較好的執行計畫，不一定是最優的，因為關聯表太多的時候，資料庫並不會窮舉所有的執行計畫，這會消耗太多的時間，oracle怎麼就知道這條資料時你要，另乙個就不是你要的呢，這是需要cpu來過濾的
2. 記憶體：sql語句和執行計畫都需要在記憶體保留一段時間，還有取到的資料，根據lru演算法也會盡量在記憶體中保留，在執行sql語句過程中，各種表之間的連線，排序等操作也要占用記憶體
3. io：如果需要的資料在記憶體中沒有，則需要到磁碟中去取，就會用到物理io了，還有表之間的連線資料太多，以及排序等操作記憶體放不下的時候，也需要用到臨時表空間，也就用到物理io了
這裡有一點說明的是，雖然oracle占用了8g的記憶體，但pga一般只佔8g的20%，對於專用伺服器模式，每次執行sql語句，表資料的運算等操作，都在pga中進行的，也就是說只能用1.6g左右的記憶體，如果多個使用者都執行
多表關聯，而且表資料又多，再加上關聯不當的話，記憶體就成為瓶頸了，所有優化sql很重要的一點就是，減少邏輯讀和物理讀
如何生成awr報告：
* 1：登陸對應的資料庫伺服器
2：找到oracle磁碟空間（d:oracle\product\10.2.0\db_1\rdbms\admin)
3：執行cmd-cd d:回車
4: cd d:oracle\product\10.2.0\db_1\rdbms\admin 回車
5：sqlplus 使用者名稱/密碼@服務連線名(例：sqlplus carmot_esz_1/carmot@igrp)
6：執行@awrrpt.sql 回車
第一步輸入型別： html
第二步輸入天數： 天數自定義（如1，代表當天，如果2，代表今天和昨天。。。）
第三步輸入開始值與結束值：（你可以看到上面列出的資料，snap值）
這個值輸入開始，與結束
第四步輸入匯出表的名稱：名稱自定義 回車
第五步，由程式自動導完。
第六：到d:oracle\product\10.2.0\db_1\rdbms\admin 目錄下。找到剛才生成的檔案。 ***x.lst檔案
具體分析過程：
* 在分析awr報告之前，首先要確定我們的系統是屬於oltp，還是olap（資料庫在安裝的時候，選擇的時候，會有乙個選項，是選擇oltp，還是olap）
對於不同的系統，效能指標的側重點是不一樣的，比如，library hit和buffer hit，在olap系統中幾乎可以忽略這倆個效能指標，而在oltp系統中，這倆個指標就非常關鍵了
* 首先要看倆個時間
elapsed: 240.00 (mins) 表明取樣時間是240分鐘，任何資料都要通過這個時間來衡量，離開了這個取樣時間，任何資料都毫無疑義
db time: 92,537.95 (mins) 表明使用者操作花費的時候，包括cpu時間喝等待時間，也許有人會覺得奇怪，為什麼在取樣的240分鐘過程中，使用者操作時間竟然有92537分鐘呢，遠遠超過了
取樣時間，原因是awr報告是乙個資料的集合，比如在一分鐘之內，乙個使用者等待了30秒，那麼10個使用者就等待了300秒，對於cpu的話，乙個cpu處理了30秒，16個cpu就是4800秒，這些時間都是以累積的方式記錄在awr報告中的。
再看sessions，可以看出連線數非常多
* 為了對資料庫有個整體的認識，先看下面的效能指標
1. buffer nowait 說明在從內訪問資料的時候，沒有經歷等待的比例，期望值是100%
2. buffer hit 說明從內訪問資料的時候，buffer的命中率的比例，期望值是100%，但100%並不代表效能就好，因為這只是乙個比例而已，舉個例子，執行一條 sql語句，# 執行計畫是需要取10000個資料塊，結果記憶體中還真有這10000個資料塊，那麼比例是100%，表面上看是效能最高的，還有乙個執行計畫是需要500 個資料塊，記憶體中有250個，另外250個需要在物理磁碟中取，
這種情況下，buffer hit是50%，結果呢，第二個執行計畫效能才是最高的，所以說100%並不代表效能最好
3. library hit 說明sql在shared pool的命中率，期望值是100%
4. execute to parse 說明解析sql和執行sql之間的比例，越高越好，說明一次解析，到處執行，如果parse多，execute少的話，還會出現負數，因為計算公式是100*（1-parse/execute）
5. parse cpu to parse elapsd 說明在解析sql語句過程中，cpu佔整個的解析時間比例，，期望值是100%，說明沒有產生等待，需要說明的是，即使有硬解析，只要cpu沒有出現效能問題，也是可以容忍的，比較硬解析也有它的好處的
6. redo nowait 說明在產生日誌的時候，沒有產生等待，期望值是100%
7. soft parse 說明軟解析的比例，期望值是100%，有一點要說明的是，不要單方面的追求軟解析的高比例，而去繫結變數，要看效能的瓶頸在**
8. latch hit 說明latch的命中率，期望值是100%，latch類似鎖，是一種記憶體鎖，但只會產生等待，不會產生阻塞，和lock還是有區別的，latch是在併發的情況下產生的
9. non-parse cpu 說明非解析cpu的比例，越高越好，用100減去這個比例，可以看出解析sql所花費的cpu，100-99.30=0.7，說明花費在解析sql上的cpu很少
* 結合time model statistics
可以看出，在整個sql執行時間（sql execute elapsed time）時間為5552019秒中，解析時間（parse time elapsed）用了36秒，硬解析時間（hard parse elapsed time）用了34秒雖然硬解析時間佔了整個解析時間的絕大部分，但解析時間是花的很少的，所以可以判斷出，sql的解析沒有成為效能的瓶頸，進一步推測，sql在獲取資料的過程中遇到了瓶 頸
* 繼續看top 5 timed events，從這裡可以看出等待時間在前五位的是什麼事件，基本上就可以判斷出效能瓶頸在什麼地方
1. buffer busy waits 說明在獲取資料的過程中，頻繁的產生等待事件，很有可能產生了熱點塊，也就是說，很多會話都去讀取同樣的資料塊，這一事件等待了5627394次，總共等待了5322924秒，平均等待時間為946毫秒，而且頻率也是最高的，有95.9%，等待類別是併發
這裡有乙個概念：oracle操作的最小單位是塊，當乙個會話要修改這個塊中的一條記錄，會讀取整個塊，如果另乙個會話要修改的資料也正好在這個塊中，雖然這倆個
2. 會話修改的記錄不一樣，也會產生等待direct path write temp和direct path read temp 說明用到了臨時表空間，那我們再看一下tablespace io stats
各項指標都是非常高的，再根據上面的in-memory sort是100%，沒有產生磁碟排序，也就在排序的時候沒有用到臨時表空間，進一步推測，多個session，每個session執行的sql語句中多表關聯，產生了很多中間資料，pga記憶體中放不下，
用到了臨時表空間，也有可能是用到了lob欄位，在用lob欄位的時候，也會用到臨時表
* 繼續看sql statistics
根據buffer busy waits等待次數，時間，頻率都是最高的，我們重點看邏輯讀，物理讀，和執行時間最長的sql，把排在前幾位的拿出來優化
優化的原則為降低物理讀，邏輯讀，sql語句中的子操作執行次數盡量少，在看oracle估計出來的執行計畫是看不出子操作的執行次數的，要看執行時的執行計畫
* 有興趣的話還可以看一下segment statistics
列出了用到的索引和表的使用情況，從這裡也能看出索引和表的使用頻率
* 也可以看一下load profile
裡面列出了每秒，每個事務所產生的日誌，邏輯讀和物理讀等指標
流柯
Oracle的AWR報告分析
今晚來分析一下awr報告，首先說一下什麼是awr報告，它能給我們帶來什麼。定義 awr報告是oracle10g下提供的一種效能收集和分析工具，它能提供乙個時間段內整個系統資源使用情況的報告，通過這個報告，我們就可以了解乙個系統的整個運 況，這就像乙個人全面的體檢報告。如何分析 在看awr報告的時候，...
oracle基礎 awr報告
重點關注 一 snapshot information session 連線的總的會話數 cursors session 每個會話平均開啟的游標數 elapsed 快照產生的總時間 通過elapsed db time比較，反映出資料庫的繁忙程度。如果awr報告頂部的db time遠大於elapsed...
AWR報告分析解讀
1 awr報告頭資訊 2 awr負載概要資訊 3 awr例項效率 4 共享池概要 5 awr top等待事件 顯示了系統中最嚴重的5個等待，按所佔等待時間的比例倒序列示。當我們調優時，總希望觀察到最顯著的效果，因此應當從這裡入手確定我們下一步做什麼。通常，在沒有問題的資料庫中，cpu time總是列...