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

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

針對這個Load Profile我們可以看出系統中存在很多高負載的點，每秒redo超過9MB，邏輯讀632萬+，物理讀高達6.4萬+/秒，一小時內的讀寫IOPS高達1.8萬+，讀IO吞吐量500MB+/秒，寫IO吞吐量15MB/秒，每秒事務數100+，每秒執行數接近5000。針對這個負載文件，我們能給它找出食材配料表嗎？

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

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

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

這時候我們需要繼續查看CPU的情況，因為從主要事件上看，CPU占比較大。從這個報告上看，LOAD居然高達500+，這對于128核，256線程的7、8年前采購的服務器來說，有點高了。

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

下一步就是怎么烹調這道菜了，煎炒烹炸，蒸煮煲湯，哪種方式更適合這些食材呢？這就是我們要制定的優化策略了。從這個系統上來看，有經驗的DBA一定會選擇先降低CPU的使用率，因為如此大的IO量，后端存儲還撐得住，沒有性能明顯下降的趨勢，在CPU與IO的選擇中，首先會選擇降CPU為主的做法。一旦確定了CPU優先的測了，那么在第一階段的優化中，REDO的問題也不需要過多的考慮了，雖然平均每秒有9MB+的REDO量，以經驗來看，全閃的SAN存儲是沒有任何問題的。

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

這個系統中的RAC GC的問題也很嚴重，要想分析如何優化GC，首先我們需要分析RAC的相關指標。

從RAC的相關指標上看，除了流量大一些以外，其他指標都正常，不算太差，說明GC問題不是系統性的，而僅僅是部分SQL不優化引發的，這種問題解決起來比較容易。在消息上，Ksxp隊列上的延時比較大，indirect sent的比例偏高了一點。這些都是和流量較大有關的。因此降低RAC INTERCONNECT的流量應該是解決這個問題的比較穩妥的方法。雖然說優化CPU使用率高的SQL有助于降低RAC流量。不過我們如果能夠針對性的解決問題，才會有更為明顯的效果。

這些TOP SEGMENT相關的SQL語句是我們本次優化的重點，在這里我們發現了一張消息表。有200GB+，其中的數據可以刪除清理。如果能夠完成這個操作，可以大大降低RAC通訊流量。

經過這樣一個個的分析，我們就基本上能夠確定第一階段的工作方案了。通過第一階段，首先解決目前最為緊迫的問題，讓系統恢復可用。然后給我們留出足夠多的時間來做精細化的全面優化。通過全面優化，讓系統煥然一新。?