本文格式為Word版，下載可任意編輯——最詳盡的AWR報(bào)告詳細(xì)分析bindprocessor-q

Theavailableprocessorsare:01234567

先說(shuō)ReportA,在snapshot間隔中，總共約60分鐘，cpu就共有60*8=480分鐘，DBtime為466.37分鐘，則：

深圳博睿同創(chuàng)信息技術(shù)有限公司

深圳博睿同創(chuàng)信息技術(shù)有限公司

cpu花費(fèi)了466.37分鐘在處理Oralce非空閑等待和運(yùn)算上(比方規(guī)律讀)

也就是說(shuō)cpu有466.37/480*100%花費(fèi)在處理Oracle的操作上，這還不包括后臺(tái)進(jìn)程看ReportB，總共約60分鐘，cpu有19.49/480*100%花費(fèi)在處理Oracle的操作上很顯然，2中服務(wù)器的平均負(fù)載很低。

從awrreport的Elapsedtime和DBTime就能大約了解db的負(fù)載。

可是對(duì)于批量系統(tǒng)，數(shù)據(jù)庫(kù)的工作負(fù)載總是集中在一段時(shí)間內(nèi)。假使快照周期不在這一段時(shí)間內(nèi)，或者快照周期跨度太長(zhǎng)而包含了大量的數(shù)據(jù)庫(kù)空閑時(shí)間，所得出的分析結(jié)果是沒(méi)有意義的。這也說(shuō)明選擇分析時(shí)間段很關(guān)鍵，要選擇能夠代表性能問(wèn)題的時(shí)間段。ReportSummaryCacheSizes

BufferCache:SharedPoolSize:Begin3,344M704MEnd704MLogBuffer:8K14,352K3,344MStdBlockSize:顯示SGA中每個(gè)區(qū)域的大?。ㄔ贏MM改變它們之后），可用來(lái)與初始參數(shù)值比較。

sharedpool主要包括librarycache和dictionarycache。librarycache用來(lái)存儲(chǔ)最近解析（或編譯）后SQL、PL/SQL和Javaclasses等。librarycache用來(lái)存儲(chǔ)最近引用的數(shù)據(jù)字典。發(fā)生在librarycache或dictionarycache的cachemiss代價(jià)要比發(fā)生在buffercache的代價(jià)高得多。因此sharedpool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache。

LoadProfile

Redosize:Logicalreads:Blockchanges:Physicalreads:Physicalwrites:Usercalls:Parses:Hardparses:Sorts:Logons:Executes:Transactions:%BlockschangedperRead:PerSecond918,805.723,521.771,817.9568.26362.59326.6938.660.030.610.01354.341.1851.62RecursiveCall%:51.72PerTransaction775,912.722,974.061,535.2257.64306.20275.8832.650.030.510.01299.23深圳博睿同創(chuàng)信息技術(shù)有限公司

深圳博睿同創(chuàng)信息技術(shù)有限公司

Rollbackpertransaction%:85.49RowsperSort:########顯示數(shù)據(jù)庫(kù)負(fù)載概況，將之與基線數(shù)據(jù)比較才具有更多的意義，假使每秒或每事務(wù)的負(fù)載變化不大，說(shuō)明應(yīng)用運(yùn)行比較穩(wěn)定。單個(gè)的報(bào)告數(shù)據(jù)只說(shuō)明應(yīng)用的負(fù)載狀況，絕大多數(shù)據(jù)并沒(méi)有一個(gè)所謂“正確〞的值，然而Logons大于每秒1~2個(gè)、Hardparses大于每秒100、全部parses超過(guò)每秒300說(shuō)明可能有爭(zhēng)用問(wèn)題。Redosize：每秒產(chǎn)生的日志大小(單位字節(jié))，可標(biāo)志數(shù)據(jù)變更頻率,數(shù)據(jù)庫(kù)任務(wù)的繁重與否。Logicalreads：每秒/每事務(wù)規(guī)律讀的塊數(shù).平?jīng)Q每秒產(chǎn)生的規(guī)律讀的block數(shù)。LogicalReads=ConsistentGets+DBBlockGetsBlockchanges：每秒/每事務(wù)修改的塊數(shù)Physicalreads：每秒/每事務(wù)物理讀的塊數(shù)Physicalwrites：每秒/每事務(wù)物理寫(xiě)的塊數(shù)Usercalls：每秒/每事務(wù)用戶(hù)call次數(shù)

Parses：SQL解析的次數(shù).每秒解析次數(shù)，包括fastparse，softparse和hardparse三種數(shù)量的綜合。軟解析每秒超過(guò)300次意味著你的\應(yīng)用程序\效率不高，調(diào)整session_cursor_cache。在這里，fastparse指的是直接在PGA中命中的狀況（設(shè)置了session_cached_cursors=n）；softparse是指在sharedpool中命中的情形；hardparse則是指都不命中的狀況。

Hardparses：其中硬解析的次數(shù)，硬解析太多，說(shuō)明SQL重用率不高。每秒產(chǎn)生的硬解析次數(shù),每秒超過(guò)100次，就可能說(shuō)明你綁定使用的不好，也可能是共享池設(shè)置不合理。這時(shí)候可以啟用參數(shù)cursor_sharing=similar|force，該參數(shù)默認(rèn)值為exact。但該參數(shù)設(shè)置為similar時(shí)，存在bug，可能導(dǎo)致執(zhí)行計(jì)劃的不優(yōu)。

Sorts：每秒/每事務(wù)的排序次數(shù)Logons：每秒/每事務(wù)登錄的次數(shù)Executes：每秒/每事務(wù)SQL執(zhí)行次數(shù)

Transactions：每秒事務(wù)數(shù).每秒產(chǎn)生的事務(wù)數(shù)，反映數(shù)據(jù)庫(kù)任務(wù)繁重與否。

BlockschangedperRead：表示規(guī)律讀用于修改數(shù)據(jù)塊的比例.在每一次規(guī)律讀中更改的塊的百分比。

RecursiveCall：遞歸調(diào)用占所有操作的比率.遞歸調(diào)用的百分比，假使有好多PL/SQL，那么這個(gè)值就會(huì)比較高。Rollbackpertransaction：每事務(wù)的回滾率.看回滾率是不是很高，由于回滾很耗資源,假使回滾率過(guò)高,可能說(shuō)明你的數(shù)據(jù)庫(kù)經(jīng)歷了太多的無(wú)效操作,過(guò)多的回滾可能還會(huì)帶來(lái)UndoBlock的競(jìng)爭(zhēng)該參數(shù)計(jì)算公式如下:Round(Userrollbacks/(usercommits+userrollbacks),4)*100%。RowsperSort：每次排序的行數(shù)注:

Oracle的硬解析和軟解析

深圳博睿同創(chuàng)信息技術(shù)有限公司

深圳博睿同創(chuàng)信息技術(shù)有限公司

提到軟解析(softprase)和硬解析(hardprase)，就不能不說(shuō)一下Oracle對(duì)sql的處理過(guò)程。當(dāng)你發(fā)出一條sql語(yǔ)句交付Oracle，在執(zhí)行和獲取結(jié)果前，Oracle對(duì)此sql將進(jìn)行幾個(gè)步驟的處理過(guò)程：1、語(yǔ)法檢查(syntaxcheck)檢查此sql的拼寫(xiě)是否語(yǔ)法。2、語(yǔ)義檢查(semanticcheck)

諸如檢查sql語(yǔ)句中的訪問(wèn)對(duì)象是否存在及該用戶(hù)是否具備相應(yīng)的權(quán)限。3、對(duì)sql語(yǔ)句進(jìn)行解析(prase)

利用內(nèi)部算法對(duì)sql進(jìn)行解析，生成解析樹(shù)(parsetree)及執(zhí)行計(jì)劃(executionplan)。

4、執(zhí)行sql，返回結(jié)果(executeandreturn)其中，軟、硬解析就發(fā)生在第三個(gè)過(guò)程里。

Oracle利用內(nèi)部的hash算法來(lái)取得該sql的hash值，然后在librarycache里查找是否存在該hash值；

假設(shè)存在，則將此sql與cache中的進(jìn)行比較；

假設(shè)“一致〞，就將利用已有的解析樹(shù)與執(zhí)行計(jì)劃，而省略了優(yōu)化器的相關(guān)工作。這也就是軟解析的過(guò)程。誠(chéng)然，假使上面的2個(gè)假設(shè)中任有一個(gè)不成立，那么優(yōu)化器都將進(jìn)行創(chuàng)立解析樹(shù)、生成執(zhí)行計(jì)劃的動(dòng)作。這個(gè)過(guò)程就叫硬解析。

創(chuàng)立解析樹(shù)、生成執(zhí)行計(jì)劃對(duì)于sql的執(zhí)行來(lái)說(shuō)是開(kāi)銷(xiāo)昂貴的動(dòng)作，所以，應(yīng)當(dāng)全力避免硬解析，盡量使用軟解析。

InstanceEfficiencyPercentages(Target100%)

BufferNowait%:BufferHit%:LibraryHit%:ExecutetoParse%:ParseCPUtoParseElapsd%:100.00RedoNoWait%:98.72In-memorySort%:99.97SoftParse%:89.09LatchHit%:7.99%Non-ParseCPU:100.0099.8699.9299.9999.95本節(jié)包含了Oracle關(guān)鍵指標(biāo)的內(nèi)存命中率及其它數(shù)據(jù)庫(kù)實(shí)例操作的效率。其中BufferHitRatio也稱(chēng)CacheHitRatio，LibraryHitratio也稱(chēng)LibraryCacheHitratio。同LoadProfile一節(jié)一致，這一節(jié)也沒(méi)有所謂“正確〞的值，而只能根據(jù)應(yīng)用的特點(diǎn)判斷是否適合。在一個(gè)使用直接讀執(zhí)行大型并行查詢(xún)的DSS環(huán)境，20%的BufferHitRatio是可以接受的，而這個(gè)值對(duì)于一個(gè)OLTP系統(tǒng)是完全不能接受的。根據(jù)Oracle的經(jīng)驗(yàn)，對(duì)于OLTP系統(tǒng)，BufferHitRatio理想應(yīng)當(dāng)在90%以上。

BufferNowait表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。在緩沖區(qū)中獲取Buffer的未等待比率。BufferNowait的這個(gè)值一般需要大于99%。否則可能存在爭(zhēng)用，可以在后面的等待事件中進(jìn)一步確認(rèn)。

bufferhit表示進(jìn)程從內(nèi)存中找到數(shù)據(jù)塊的比率，監(jiān)視這個(gè)值是否發(fā)生重大變化比這個(gè)值本身更重要。對(duì)于一般的OLTP系統(tǒng)，假使此值低于80%，應(yīng)當(dāng)給數(shù)據(jù)庫(kù)分派更多的內(nèi)存。數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率，尋常應(yīng)在95%以上。否

深圳博睿同創(chuàng)信息技術(shù)有限公司

深圳博睿同創(chuàng)信息技術(shù)有限公司

則，小于95%，需要調(diào)整重要的參數(shù)，小于90%可能是要加db_cache_size。一個(gè)高的命中率，不一定代表這個(gè)系統(tǒng)的性能是最優(yōu)的，譬如大量的非選擇性的索引被頻繁訪問(wèn)，就會(huì)造成命中率很高的假相（大量的dbfilesequentialread），但是一個(gè)比較低的命中率，一般就會(huì)對(duì)這個(gè)系統(tǒng)的性能產(chǎn)生影響，需要調(diào)整。命中率的突變，往往是一個(gè)不好的信息。假使命中率突然增大，可以檢查topbuffergetSQL，查看導(dǎo)致大量規(guī)律讀的語(yǔ)句和索引，假使命中率突然減小，可以檢查topphysicalreadsSQL，檢查產(chǎn)生大量物理讀的語(yǔ)句，主要是那些沒(méi)有使用索引或者索引被刪除的。

RedoNoWait表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。假使太低（可參考90%閥值），考慮增加LOGBUFFER。當(dāng)redobuffer達(dá)到1M時(shí)，就需要寫(xiě)到redolog文件，所以一般當(dāng)redobuffer設(shè)置超過(guò)1M，不太可能存在等待buffer空間分派的狀況。當(dāng)前，一般設(shè)置為2M的redobuffer，對(duì)于內(nèi)存總量來(lái)說(shuō)，應(yīng)當(dāng)不是一個(gè)太大的值。

libraryhit表示Oracle從LibraryCache中檢索到一個(gè)解析過(guò)的SQL或PL/SQL語(yǔ)句的比率，當(dāng)應(yīng)用程序調(diào)用SQL或存儲(chǔ)過(guò)程時(shí)，Oracle檢查L(zhǎng)ibraryCache確定是否存在解析過(guò)的版本，假使存在，Oracle馬上執(zhí)行語(yǔ)句；假使不存在，Oracle解析此語(yǔ)句，并在LibraryCache中為它分派共享SQL區(qū)。低的libraryhitratio會(huì)導(dǎo)致過(guò)多的解析，增加CPU消耗，降低性能。假使libraryhitratio低于90%，可能需要調(diào)大sharedpool區(qū)。STATEMENT在共享區(qū)的命中率，尋常應(yīng)當(dāng)保持在95%以上，否則需要要考慮：加大共享池；使用綁定變量；修改cursor_sharing等參數(shù)。

LatchHit：Latch是一種保護(hù)內(nèi)存結(jié)構(gòu)的鎖，可以認(rèn)為是SERVER進(jìn)程獲取訪問(wèn)內(nèi)存數(shù)據(jù)結(jié)構(gòu)的許可。要確保LatchHit>99%，否則意味著SharedPoollatch爭(zhēng)用，可能由于未共享的SQL，或者LibraryCache太小，可使用綁定變更或調(diào)大SharedPool解決。要確保>99%，否則存在嚴(yán)重的性能問(wèn)題。當(dāng)該值出現(xiàn)問(wèn)題的時(shí)候，我們可以借助后面的等待時(shí)間和latch分析來(lái)查找解決問(wèn)題。

ParseCPUtoParseElapsd：解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間)，越高越好。計(jì)算公式為：ParseCPUtoParseElapsd%=100*(parsetimecpu/parsetimeelapsed)。即：解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間)。假使該比率為100%，意味著CPU等待時(shí)間為0，沒(méi)有任何等待。

Non-ParseCPU：SQL實(shí)際運(yùn)行時(shí)間/(SQL實(shí)際運(yùn)行時(shí)間+SQL解析時(shí)間)，太低表示解析消耗時(shí)間過(guò)多。計(jì)算公式為：%Non-ParseCPU

=round(100*1-PARSE_CPU/TOT_CPU),2)。假使這個(gè)