星期六上午閑來無事,曬著太陽,來分析一下awr報告,首先說一下什么是awr報告,它能給我們帶來什么。
??? * 定義: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 目錄下。找到剛才生成的文件。 XXXX.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
????? 里面列出了每秒,每個事務所產生的日志,邏輯讀和物理讀等指標
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
