AWR報(bào)告中對(duì)各內(nèi)存組件的Advisory

1、DCS組需要進(jìn)行內(nèi)存調(diào)整，因此通過這一周的數(shù)據(jù)庫運(yùn)行，積累了一定的數(shù)據(jù)，我們只選Memory Advisory部分，來說下AWR部分中，Oracle自己對(duì)我們提出的內(nèi)存調(diào)整的建議。這些建議是oracle通過自身設(shè)置一個(gè)模擬環(huán)境，把內(nèi)存組建設(shè)置不同的大小的建議，對(duì)于這種改變?cè)斐傻南嚓P(guān)方面的性能影響進(jìn)行估算，最后將這個(gè)估算清單提交給我們。這幾部分并不能幫助我們直觀的定位系統(tǒng)問題，但是它會(huì)給我們一些關(guān)于oracle內(nèi)存大小的建議，所以我們應(yīng)該關(guān)注一下這里，以便知道當(dāng)前數(shù)據(jù)庫在這方面的設(shè)置是否合理。可能因此各ORACLE和版本不同，AWR的樣式不太一樣，但主要的部分是差不多的，DCS PROD是11g

2、r2，我們以此為例。而且AWR報(bào)告取的時(shí)間段為一周，而且AWR報(bào)告的原始數(shù)據(jù)在DB中也只能存一星期。我們從AWR報(bào)告的先后順序說起。主要部分有：Buffer Pool AdvisoryPGA Memory AdvisoryShared Pool AdvisorySGA Target Advisory我們來看下各列的含義：Size for Est(M)Oracle估算Buffer pool的大小Size Factor估算值和實(shí)際值的一個(gè)比例，比如0.9就是估算值是實(shí)際大小的90%，1.0表示buffer pool的實(shí)際大小Buffers for Estimate估算的buffer的大小（數(shù)量）E

3、st Phys Read Factor估算的物理讀的影響因子，是估算物理讀和實(shí)際物理讀的一個(gè)比例，1.0表示實(shí)際的物理讀Estimated Physical Reads估算的物理讀次數(shù)我們首先找到目前的buffer pool值，即Size Factor是1.00的地方，1,152。我們隨著Size Factor不斷變大，來看下物理讀（這是我們最關(guān)于的結(jié)果）的變化情況。當(dāng)buffer pool變成現(xiàn)在的1.07-1.56倍的時(shí)候，物理讀下降的明不明顯，但增加為1.65倍時(shí)，開始有所降低，當(dāng)增加為1.75倍，時(shí)，物理讀將變?yōu)楝F(xiàn)在的38%。這將是一個(gè)可以考慮的平衡點(diǎn)。但再繼續(xù)增加buffer poo

4、l時(shí)，物理讀下降的并不明顯，即收益不大，不予考慮。因此，若在server總內(nèi)存充足的情況下，將buffer pool（隸屬于sga）增加至2128m是一個(gè)不錯(cuò)的選擇。我們來看下各列的含義：PGA Target Est (MB)PGA的估算大小Size Factr影響因子，作用和buffer pool相同W/A MB ProcessedOracle為了產(chǎn)生估算處理的數(shù)據(jù)量Estd Extra W/A MB處理數(shù)據(jù)中需要物理讀寫的數(shù)據(jù)量Estd PGA Cache Hit %     估算的PGA命中率Estd PGA Overalloc Coun

5、t需要在估算的PGA大小額外分配內(nèi)存的次數(shù)由于此圖過于炫富，無可參考性，即就算PGA變?yōu)楝F(xiàn)在的1/10，物理讀也不會(huì)增加，沒什么可比性，說明：這庫在這周內(nèi)太閑了。我們來看下DCS PROD之前的一個(gè)AWR情況：最初PGA只有200M，我即建議SYSTEM TEAM增加至400M+，為什么呢。我們注意到，亦以當(dāng)時(shí)的200M為1.00的參數(shù)因子，當(dāng)變成2倍的400M時(shí)，物理讀從5537驟降至5，幾個(gè)數(shù)量級(jí)之前的差距，因此多增加200M的內(nèi)存，收益是非常大的。但是，從400M增加至500M或者是更大，物理讀降低的可憐，但將付出更多的總內(nèi)存，因此是不太劃算的。當(dāng)然，我們也需要有未雨綢繆的心態(tài)，可以考慮

6、酌情添加，比如像現(xiàn)在的500M，就是一個(gè)比較適合的數(shù)值了。我們現(xiàn)在來看下對(duì)數(shù)據(jù)庫性能最大的shared pool的情況，我們來看下各列的含義：Shared Pool Size(M)         估算共享池的大小SP Size Factr    估算共享池的影響因子Est LC Size (M)         估算的庫高速緩存占用的大?。↙C，library cache）E

7、st LC Mem Obj      高速緩沖區(qū)命中的對(duì)象數(shù)Est LC Time Saved (s)      需要額外將對(duì)象讀入共享池的時(shí)間Est LC Time Saved Factr 影響因子Est LC Load Time (s)分析所花費(fèi)的時(shí)間Est LC Load Time Factr   分析花費(fèi)時(shí)間事件的影響因子Est LC Mem Obj Hits內(nèi)存中對(duì)象被發(fā)現(xiàn)的次數(shù)不同與前2個(gè)的是，我們最關(guān)心的因子是Est LC

8、 Time Saved Factr，它表示每模擬一次sharedpool大小將對(duì)對(duì)象讀入共享池的影響情況，當(dāng)這個(gè)值變化很小或者不變的時(shí)候，增加shared pool就沒有多大意義比如Est LC Time Saved Factr=1，隨著內(nèi)存的增大，它的值變化顯得非常小，所以我們認(rèn)為當(dāng)前共享池大小事合適的。我們順手瞄一眼4PL的情況：我們發(fā)現(xiàn)當(dāng)shared pool從當(dāng)時(shí)值的80%之后，Est LC Time Saved Factr即不再增加，因此是夠用的。因此我取的都是一整個(gè)星期的情況，而且SGA都是自動(dòng)的動(dòng)態(tài)調(diào)整的，從連續(xù)幾星期來看都是如此的話，說明。4PL還是蠻富有的。各列說明：SGA

9、Target Size (M)估算SGA大小SGA Size Factor       SGA大小的影響因子Est DB Time (s)估算的SGA大小計(jì)算出的DB TimeEst Physical Reads物理讀次數(shù)SGA這部分比較簡單，我們看到當(dāng)前的SGA大小基本上是合適的，當(dāng)影響因子從0.75到1時(shí)，物理讀減少了很多，下面的影響程度就沒有那么大了。當(dāng)SYSTEM TEAM讓我們提出自己內(nèi)存的需求時(shí)，提供一段時(shí)間內(nèi)（一般是一星期，而且AWR報(bào)告的原始數(shù)據(jù)也只能存一星期）Oracle的AWR報(bào)告，會(huì)

10、是非常有力的證據(jù)。因此對(duì)于DCS PROD庫的建議是，加大SGA至4G，并手工指定buffer pool在sga中大小不低于2G。當(dāng)然，當(dāng)時(shí)system temp已經(jīng)跟我們說是sga會(huì)給我們5G，我們就心安理得的接受好了。你懂的?？傮w來說，DCS PROD這周是非常清閑的，為什么？我們回頭看下AWR報(bào)告最開始的部分：它包含了數(shù)據(jù)和實(shí)例的一個(gè)基本信息，如果是一個(gè)rac結(jié)構(gòu)，RAC選項(xiàng)為YES，最好對(duì)每個(gè)實(shí)例做性能分析。這部分是采集周期里系統(tǒng)的一個(gè)概述，要注意下面三個(gè)列的含義：1、 sessions表示采集是實(shí)例連接的會(huì)話數(shù)，這個(gè)數(shù)可以讓我們了解數(shù)據(jù)庫并發(fā)用戶的大概情況。如果是新接手的數(shù)據(jù)庫，對(duì)判

11、斷數(shù)據(jù)庫的類型可以做參考2、 Cursors/Session，平均每個(gè)會(huì)話卡開的游標(biāo)數(shù)。3、 DB Time 這個(gè)數(shù)值比較重要，它表示用戶操作花費(fèi)的時(shí)間，包括cpu和等待事件。有時(shí)候DB Time會(huì)比Elapsed時(shí)間要長。因?yàn)锳WR是一個(gè)數(shù)據(jù)的合集，比如說1分鐘內(nèi)一個(gè)用戶等待10秒鐘，那么10個(gè)用戶是300秒（5分鐘）；cpu的時(shí)間也是一樣一分鐘之內(nèi)，一個(gè)cpu處理30秒，那么4個(gè)cpu就是1.2分鐘，8個(gè)就是2.4分鐘，這些都以累計(jì)的方式記錄在awr報(bào)告當(dāng)中的。我們注意到，DB Time是要小于自然時(shí)間的，這說明。此庫非常閑。因?yàn)榇藥鞛镺LTP類型的庫，我們?cè)倭粢庀?個(gè)值，Library Hit/Buffer Hit。即AWR報(bào)告的下一部分：除去Library Hit略低之外，整體的性能指標(biāo)還是不錯(cuò)的?？赡苡械耐聲?huì)問，execute to parse這里很低是不是數(shù)據(jù)庫有問題了呢？不一定的。這不是綁定變量的問題。這個(gè)比例是由于太多的soft parse導(dǎo)致的，對(duì)于比如我們的web服務(wù)，這個(gè)值很小是正常的。因?yàn)橛脩粢磸?fù)鏈接，每一次鏈接及時(shí)相同的sql，都會(huì)有一次soft parse。這個(gè)