星期六上午閑來無事,曬著太陽,來分析一下awr報告,首先說一下什么是awr報告,它能給我們帶來什么。
??? * 定義:awr報告是oracle 10g下提供的一種性能收集和分析工具,它能提供一個時間段內(nèi)整個系統(tǒng)資源使用情況的報告,通過這個報告,我們就可以了解一個系統(tǒng)的整個運行情況,這就像一個人全面的體檢報告。
如何分析:
??? * 在看awr報告的時候,我們并不需要知道所有性能指標(biāo)的含義,就可以判斷出問題的所在,這些性能指標(biāo)其實代表了oracle內(nèi)部實現(xiàn),對oracle理解的越深,在看awr報告的時候,對數(shù)據(jù)庫性能的判斷也會越準(zhǔn)確
??? * 在看性能指標(biāo)的時候,心里先要明白,數(shù)據(jù)庫出現(xiàn)性能問題,一般都在三個地方,io,內(nèi)存,cpu,這三個又是息息相關(guān)的(ps:我們先假設(shè)這個三個地方都沒有物理上的故障),當(dāng)io負(fù)載增大時,肯定需要更多的內(nèi)存來存放,同時也需要cpu花費更多的時間來過濾這些數(shù)據(jù),相反,cpu時間花費多的話,有可能是解析sql語句,也可能是過濾太多的數(shù)據(jù),到不一定是和io或內(nèi)存有關(guān)系了
??? * 當(dāng)我們把一條sql送到數(shù)據(jù)庫去執(zhí)行的時候,我們要知道,什么時候用到cpu,什么時候用到內(nèi)存,什么時候用到io
?? 1. cpu:解析sql語句,嘗試多個執(zhí)行計劃,最后生成一個數(shù)據(jù)庫認(rèn)為是比較好的執(zhí)行計劃,不一定是最優(yōu)的,因為關(guān)聯(lián)表太多的時候,數(shù)據(jù)庫并不會窮舉所有的執(zhí)行計劃,這會消耗太多的時間,oracle怎么就知道這條數(shù)據(jù)時你要,另一個就不是你要的呢,這是需要cpu來過濾的
?? 2. 內(nèi)存:sql語句和執(zhí)行計劃都需要在內(nèi)存保留一段時間,還有取到的數(shù)據(jù),根據(jù)lru算法也會盡量在內(nèi)存中保留,在執(zhí)行sql語句過程中,各種表之間的連接,排序等操作也要占用內(nèi)存
?? 3. io:如果需要的數(shù)據(jù)在內(nèi)存中沒有,則需要到磁盤中去取,就會用到物理io了,還有表之間的連接數(shù)據(jù)太多,以及排序等操作內(nèi)存放不下的時候,也需要用到臨時表空間,也就用到物理io了
這里有一點說明的是,雖然oracle占用了8G的內(nèi)存,但pga一般只占8G的20%,對于專用服務(wù)器模式,每次執(zhí)行sql語句,表數(shù)據(jù)的運算等操作,都在pga中進(jìn)行的,也就是說只能用1.6G左右的內(nèi)存,如果多個用戶都執(zhí)行
多表關(guān)聯(lián),而且表數(shù)據(jù)又多,再加上關(guān)聯(lián)不當(dāng)?shù)脑挘瑑?nèi)存就成為瓶頸了,所有優(yōu)化sql很重要的一點就是,減少邏輯讀和物理讀
如何生成awr報告:
??? * 1:登陸對應(yīng)的數(shù)據(jù)庫服務(wù)器
2:找到oracle磁盤空間(d:oracle\product\10.2.0\db_1\RDBMS\Admin)
3:執(zhí)行cmd-cd d:回車
4: cd? d:oracle\product\10.2.0\db_1\RDBMS\Admin 回車
5:sqlplus 用戶名/密碼@服務(wù)連接名(例:sqlplus carmot_esz_1/carmot@igrp)
6:執(zhí)行@awrrpt.sql 回車
第一步輸入類型: html
第二步輸入天數(shù): 天數(shù)自定義(如1,代表當(dāng)天,如果2,代表今天和昨天。。。)
第三步輸入開始值與結(jié)束值:(你可以看到上面列出的數(shù)據(jù),snap值)
????? 這個值輸入開始,與結(jié)束
第四步輸入導(dǎo)出表的名稱:名稱自定義 回車
第五步,由程序自動導(dǎo)完。
第六:到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目錄下。找到剛才生成的文件。 XXXX.LST文件
具體分析過程:?
??? * 在分析awr報告之前,首先要確定我們的系統(tǒng)是屬于oltp,還是olap(數(shù)據(jù)庫在安裝的時候,選擇的時候,會有一個選項,是選擇oltp,還是olap)
????? 對于不同的系統(tǒng),性能指標(biāo)的側(cè)重點是不一樣的,比如,library hit和buffer hit,在olap系統(tǒng)中幾乎可以忽略這倆個性能指標(biāo),而在oltp系統(tǒng)中,這倆個指標(biāo)就非常關(guān)鍵了
??? * 首先要看倆個時間
????? Elapsed: 240.00 (mins) 表明采樣時間是240分鐘,任何數(shù)據(jù)都要通過這個時間來衡量,離開了這個采樣時間,任何數(shù)據(jù)都毫無疑義
????? DB Time: 92,537.95 (mins) 表明用戶操作花費的時候,包括cpu時間喝等待時間,也許有人會覺得奇怪,為什么在采樣的240分鐘過程中,用戶操作時間竟然有92537分鐘呢,遠(yuǎn)遠(yuǎn)超過了
????? 采樣時間,原因是awr報告是一個數(shù)據(jù)的集合,比如在一分鐘之內(nèi),一個用戶等待了30秒,那么10個用戶就等待了300秒,對于cpu的話,一個cpu處理了30秒,16個cpu就是4800秒,這些時間都是以累積的方式記錄在awr報告中的。
????????? 再看sessions,可以看出連接數(shù)非常多
??? * 為了對數(shù)據(jù)庫有個整體的認(rèn)識,先看下面的性能指標(biāo)
?
??
?
?? 1. Buffer Nowait 說明 在從內(nèi)存取數(shù)據(jù)的時候,沒有經(jīng)歷等待的比例,期望值是100%
?? 2. Buffer Hit 說明從內(nèi)存取數(shù)據(jù)的時候,buffer的命中率的比例,期望值是100%,但100%并不代表性能就好,因為這只是一個比例而已,舉個例子,執(zhí)行一條 sql語句,# 執(zhí)行計劃是需要取10000個數(shù)據(jù)塊,結(jié)果內(nèi)存中還真有這10000個數(shù)據(jù)塊,那么比例是100%,表面上看是性能最高的,還有一個執(zhí)行計劃是需要500 個數(shù)據(jù)塊,內(nèi)存中有250個,另外250個需要在物理磁盤中取,
????? 這種情況下,buffer hit是50%,結(jié)果呢,第二個執(zhí)行計劃性能才是最高的,所以說100%并不代表性能最好
?? 3. Library Hit 說明sql在Shared Pool的命中率,期望值是100%
?? 4. Execute to Parse 說明解析sql和執(zhí)行sql之間的比例,越高越好,說明一次解析,到處執(zhí)行,如果parse多,execute少的話,還會出現(xiàn)負(fù)數(shù),因為計算公式是100*(1-parse/execute)
?? 5. Parse CPU to Parse Elapsd 說明在解析sql語句過程中,cpu占整個的解析時間比例,,期望值是100%,說明沒有產(chǎn)生等待,需要說明的是,即使有硬解析,只要cpu沒有出現(xiàn)性能問題,也是可以容忍的,比較硬解析也有它的好處的
?? 6. Redo NoWait 說明在產(chǎn)生日志的時候,沒有產(chǎn)生等待,期望值是100%
?? 7. Soft Parse 說明軟解析的比例,期望值是100%,有一點要說明的是,不要單方面的追求軟解析的高比例,而去綁定變量,要看性能的瓶頸在哪里
?? 8. Latch Hit 說明latch的命中率,期望值是100%,latch類似鎖,是一種內(nèi)存鎖,但只會產(chǎn)生等待,不會產(chǎn)生阻塞,和lock還是有區(qū)別的,latch是在并發(fā)的情況下產(chǎn)生的
?? 9. Non-Parse CPU 說明非解析cpu的比例,越高越好,用100減去這個比例,可以看出解析sql所花費的cpu,100-99.30=0.7,說明花費在解析sql上的cpu很少
??? * 結(jié)合Time Model Statistics
?
???????? 可以看出,在整個sql執(zhí)行時間(sql execute elapsed time)時間為5552019秒中,解析時間(parse time elapsed)用了36秒,硬解析時間(hard parse elapsed time)用了34秒雖然硬解析時間占了整個解析時間的絕大部分,但解析時間是花的很少的,所以可以判斷出,sql的解析沒有成為性能的瓶 頸,進(jìn)一步推測,sql在獲取數(shù)據(jù)的過程中遇到了瓶??????????? 頸
??? * 繼續(xù)看Top 5 Timed Events,從這里可以看出等待時間在前五位的是什么事件,基本上就可以判斷出性能瓶頸在什么地方
?
?? 1. buffer busy waits 說明在獲取數(shù)據(jù)的過程中,頻繁的產(chǎn)生等待事件,很有可能產(chǎn)生了熱點塊,也就是說,很多會話都去讀取同樣的數(shù)據(jù)塊,這一事件等待了5627394次,總共等待了5322924秒,平均等待時間為946毫秒,而且頻率也是最高的,有95.9%,等待類別是并發(fā)
????? 這里有一個概念:oracle操作的最小單位是塊,當(dāng)一個會話要修改這個塊中的一條記錄,會讀取整個塊,如果另一個會話要修改的數(shù)據(jù)也正好在這個塊中,雖然這倆個
?? 2. 會話修改的記錄不一樣,也會產(chǎn)生等待direct path write temp和direct path read temp 說明用到了臨時表空間,那我們再看一下Tablespace IO Stats
?
????????? 各項指標(biāo)都是非常高的,再根據(jù)上面的In-memory Sort是100%,沒有產(chǎn)生磁盤排序,也就在排序的時候沒有用到臨時表空間,進(jìn)一步推測,多個session,每個session執(zhí)行的sql語句中多表關(guān)聯(lián),產(chǎn)生了很多中間數(shù)據(jù),pga內(nèi)存中放不下,
????????? 用到了臨時表空間,也有可能是用到了lob字段,在用lob字段的時候,也會用到臨時表
??? * 繼續(xù)看SQL Statistics
????? 根據(jù)buffer busy waits等待次數(shù),時間,頻率都是最高的,我們重點看邏輯讀,物理讀,和執(zhí)行時間最長的sql,把排在前幾位的拿出來優(yōu)化
????? 優(yōu)化的原則為降低物理讀,邏輯讀,sql語句中的子操作執(zhí)行次數(shù)盡量少,在看oracle估計出來的執(zhí)行計劃是看不出子操作的執(zhí)行次數(shù)的,要看運行時的執(zhí)行計劃
??? * 有興趣的話還可以看一下Segment Statistics
????? 列出了用到的索引和表的使用情況,從這里也能看出索引和表的使用頻率
??? * 也可以看一下Load Profile
????? 里面列出了每秒,每個事務(wù)所產(chǎn)生的日志,邏輯讀和物理讀等指標(biāo)
?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

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