library hit
buffer hit

--這兩項應該特別關注

報告的第一部分：它包含了一些資料庫和例項的資訊

sessions
--採集例項連線的會話數，瞭解併發使用者的大概情況，判斷資料庫的型別很有用

db time
--這個資料比較重要，它表示使用者操作花費的時間，包括cpu時間和等待時間，
eg:在60分鐘的週期中，使用者的時間佔用了422分鐘，這個比例是相關高的，說明資料庫比較繁忙，如果我們看到這樣的資訊，那麼應該到top5的等待部分去檢視究竟是什麼事件佔用了系統如此多的時間

load profile中
--physical reads 可以看到資料庫的執行情況有一個大概的瞭解，這個資料庫看起來還是比較繁忙的，有比較大的io操作

instance efficient percentages
--這部分是記憶體效率的統計資訊，這些值都應該可能接近100

如果這部分哪個資料偏低，就要做相關的分析研究：
比如soft parse%偏低，說明系統中有些sql沒有重用，最可能的原因就是沒有繫結變數；
buffer hit%太低，說明有很多資料塊沒有快取到記憶體中，可能原因就是記憶體太小，
buffer nowait%值太小，說明發生sql訪問資料塊時資料庫正在別別的會話讀入記憶體，需要等待這個操作完成，發生這樣的事情通常是某些資料塊變成了熱快

top 5 timed events
--這一部分是awr最重要的一部分，基本上首先會看這兒

db file sequential read
--它通常指的是在訪問索引資料塊時會以db file sequential read方式來將資料塊讀入到記憶體中
db ```超過30%，從這個資料可以看出資料塊中移動執行著非常多的大查詢，這個等待時間通常是由sql語句造成的，看看它是否存在效能的問題

cpu
--time看起來比較高--4907，比1小時高，這個和機器的cpu有關

latch
--共享池爭用等待事件，
可能是併發太多，也就是多個會話可能在爭用相同的資源，

top5 timed events
如果這一部分顯示前5位等待事件一共也沒有等待多久，比如第一位在幾分鐘等待，那麼就沒必要做效能上的最佳化

--對一個系統來講，我們可能需要多做幾次這樣的報告，以便得到所有事件段的效能資料

time model statistics
--這一部分資訊列出了各種操作佔用的資料庫時間比例，這也是很有用的一部分，我們從這個列表立刻就發現，

awr學習

相關文章