?優(yōu)化這個(gè)話題是很多朋友感興趣的，今天就再聊聊。很多人說給系統(tǒng)做優(yōu)化就像醫(yī)生治病，用藥的君臣佐輔，下藥的順序都不能差了。我不懂中醫(yī)之術(shù)，因此不好類比。不過我懂炒菜，就用炒菜的道理來聊聊優(yōu)化這項(xiàng)工作吧。

要想讓一道菜好吃，炒菜的主料配料選擇與配比十分關(guān)鍵，只有主料一味未免單調(diào)，而選擇比較搶戲的配料也不合適，會(huì)把主料的味道給沖了，讓菜的味道變得比較怪異。合適的主配料搭配和配比是一道菜好吃不好吃的基礎(chǔ)。

針對(duì)這個(gè)Load Profile我們可以看出系統(tǒng)中存在很多高負(fù)載的點(diǎn)，每秒redo超過9MB，邏輯讀632萬+，物理讀高達(dá)6.4萬+/秒，一小時(shí)內(nèi)的讀寫IOPS高達(dá)1.8萬+，讀IO吞吐量500MB+/秒，寫IO吞吐量15MB/秒，每秒事務(wù)數(shù)100+，每秒執(zhí)行數(shù)接近5000。針對(duì)這個(gè)負(fù)載文件，我們能給它找出食材配料表嗎？

也許有些朋友還比較謹(jǐn)慎，還需要繼續(xù)看看等待事件和命中率的情況再下結(jié)論。從命中率上好像也看不出啥來，都是較高負(fù)載的系統(tǒng)應(yīng)該有的命中率情況。唯一低點(diǎn)的是library Cache的命中率和軟解析的比例。不過從解析占用的CPU資源上看，問題似乎也不算太大。

從等待事件上看，好像除了DB CPU外，都是gc方面的問題，單塊讀等待只占3.4%，而且平均延時(shí)只有1毫秒，說明存儲(chǔ)性能不錯(cuò)。確實(shí)，本系統(tǒng)的主要數(shù)據(jù)都在閃存盤上。

從等待事件的分類統(tǒng)計(jì)上看，DB CPU占了近一半，cluster排第二位，占了26.9%。似乎解決掉這兩個(gè)問題，系統(tǒng)的主要問題就都解決了。不過到這里我們還是無法做出很好的判斷，必須繼續(xù)分析。

這時(shí)候我們需要繼續(xù)查看CPU的情況，因?yàn)閺闹饕录峡矗珻PU占比較大。從這個(gè)報(bào)告上看，LOAD居然高達(dá)500+，這對(duì)于128核，256線程的7、8年前采購的服務(wù)器來說，有點(diǎn)高了。

從OSW的數(shù)據(jù)上，我們也驗(yàn)證了CPU負(fù)載很高的問題。這套系統(tǒng)是問題十分嚴(yán)重的，因此現(xiàn)象表現(xiàn)其實(shí)是十分明顯的，很容易找到我們需要的食材。CPU使用率過高、IO負(fù)載過高、REDO量過大、集群等待比較嚴(yán)重、共享池存在一定問題。這些都是目前系統(tǒng)存在問題的關(guān)鍵，也就是我們要享用的食材。

下一步就是怎么烹調(diào)這道菜了，煎炒烹炸，蒸煮煲湯，哪種方式更適合這些食材呢？這就是我們要制定的優(yōu)化策略了。從這個(gè)系統(tǒng)上來看，有經(jīng)驗(yàn)的DBA一定會(huì)選擇先降低CPU的使用率，因?yàn)槿绱舜蟮腎O量，后端存儲(chǔ)還撐得住，沒有性能明顯下降的趨勢(shì)，在CPU與IO的選擇中，首先會(huì)選擇降CPU為主的做法。一旦確定了CPU優(yōu)先的測(cè)了，那么在第一階段的優(yōu)化中，REDO的問題也不需要過多的考慮了，雖然平均每秒有9MB+的REDO量，以經(jīng)驗(yàn)來看，全閃的SAN存儲(chǔ)是沒有任何問題的。

選定了烹飪方法之后，就要考慮烹制的細(xì)節(jié)了。先熗鍋還是先爆鍋，用葷油還是素油，加蔥姜還是大蒜？這種選擇奠定了采的基本味道，因此不得不重視。因?yàn)檫@套系統(tǒng)的優(yōu)化需求十分緊急，因此找出一些邏輯讀較高，CPU使用量較高的SQL，看看能不能通過添加索引，糾正執(zhí)行計(jì)劃等方法把CPU降一降。給后續(xù)的全面優(yōu)化爭取出一定的時(shí)間。

這個(gè)系統(tǒng)中的RAC GC的問題也很嚴(yán)重，要想分析如何優(yōu)化GC，首先我們需要分析RAC的相關(guān)指標(biāo)。

從RAC的相關(guān)指標(biāo)上看，除了流量大一些以外，其他指標(biāo)都正常，不算太差，說明GC問題不是系統(tǒng)性的，而僅僅是部分SQL不優(yōu)化引發(fā)的，這種問題解決起來比較容易。在消息上，Ksxp隊(duì)列上的延時(shí)比較大，indirect sent的比例偏高了一點(diǎn)。這些都是和流量較大有關(guān)的。因此降低RAC INTERCONNECT的流量應(yīng)該是解決這個(gè)問題的比較穩(wěn)妥的方法。雖然說優(yōu)化CPU使用率高的SQL有助于降低RAC流量。不過我們?nèi)绻軌蜥槍?duì)性的解決問題，才會(huì)有更為明顯的效果。

這些TOP SEGMENT相關(guān)的SQL語句是我們本次優(yōu)化的重點(diǎn)，在這里我們發(fā)現(xiàn)了一張消息表。有200GB+，其中的數(shù)據(jù)可以刪除清理。如果能夠完成這個(gè)操作，可以大大降低RAC通訊流量。

經(jīng)過這樣一個(gè)個(gè)的分析，我們就基本上能夠確定第一階段的工作方案了。通過第一階段，首先解決目前最為緊迫的問題，讓系統(tǒng)恢復(fù)可用。然后給我們留出足夠多的時(shí)間來做精細(xì)化的全面優(yōu)化。通過全面優(yōu)化，讓系統(tǒng)煥然一新。?