資料庫最佳化專案的流程之方案 zt

http://blog.oraclefans.cn/baishan1/entry/dba%E6%97%A5%E8%AE%B0_%E7%AC%AC%E4%B8%80%E9%83%A8_%E5%90%8E%E8%AE%B0_2_%E4%BC%98%E5%8C%96%E9%A1%B9%E7%9B%AE%E7%9A%84%E6%B5%81%E7%A8%8B%E4%B9%8B%E6%96%B9%E6%A1%88[@more@]zy

0.1.1. 最佳化專案的流程之方案

最佳化方案的設計是整個最佳化專案成敗的關鍵，透過對系統的全面分析，為系統設計合理的最佳化方案，需要方案的設計者對系統有很強的理解，並且能夠針對每個可能的效能問題提出針對性的最佳化方案。

編 寫最佳化方案分為兩個階段，第一階段是透過分析資料提出最佳化的整體思路與方案。針對一個效能問題，可能存在多種最佳化方案，但是最終採取哪種方案是十分值得仔 細斟酌的。很多DBA在有多種最佳化方案可以選擇的情況下經常會選擇一些能夠充分體現出其技術能力的方案，而往往缺乏對這些實施方案可能存在的風險的評估。 經常有些DBA讓我幫他們稽核最佳化方案。這些最佳化方案往往都是提出一系列系統存在的問題，然後針對這些問題，一對一的提出最佳化方案。這種最佳化方案實際上是 很粗糙的，僅僅是針對某個問題提出相應的方案。這些方案是否可行，是否存在風險，就沒有人關心了。事實上，我們是在做一個整體最佳化專案，而不是做一個區域性 的最佳化。我們在做資料庫維護的時候經常會碰到需要做區域性最佳化的情況，某個系統出現了效能問題，而這個效能問題的原因是由某個原因導致的，只要解決了這個問 題，那麼這個系統最佳化的工作就完成了。對於整體最佳化的專案，是基於某個目標的，而不是基於某個系統症狀，因此我們需要的是實現最佳化目標，而不是羅列最佳化技 術。

因 此在設計最佳化方案的時候，我們要考慮我們的最佳化目標，如何透過針對某些問題的調整，來實現我們的最佳化目標，才是我們再做最佳化方案設計的時候的關鍵點。因此 在做效能分析的時候，我們必須明確什麼是本系統的系統效能問題的關鍵，我們在設計最佳化方案的時候，也要圍繞這些關鍵點來展開。如果某個等待事件，佔系統總 等待事件的5%，那麼我們在解決這個問題的時候，就要考慮解決這個問題可能給我們帶來的風險有多大，實施方案的難度有多大，我們解決這個問題所花的代價是 否和收益成正比。如果實施這個最佳化存在較大的風險，那麼我們甚至可以放棄對這個問題的最佳化。反過來，如果我們碰到了一個佔整個等待事件超過50%的問題， 那麼這個效能問題將作為我們本次最佳化的重點，無論花費怎樣的代價，我們都必須解決這個問題，否則我們就很難達成我們預期的最佳化目標。有經驗的DBA在進行 最佳化的時候，都能夠很好的識別主要矛盾和次要矛盾，把有限的精力都放在解決主要矛盾上，這樣才能夠提高專案成功的機會，同時避免不必要的風險。

在 設計最佳化方案的時候，如何合理的規避風險也是十分關鍵的，絕大多數最佳化方案都不是唯一的，往往我們都會有多個方案可選，如何選取一個合理的最佳化方案將十分 關鍵。這一點也往往成為有經驗的DBA和經驗不足的DBA之間最大的不同。在有多個方案可以選擇的時候，往往需要有資深的DBA參與審定，才能夠保證最佳化 工作不會出現嚴重的偏差，在這個時候，需要透過評審會的方式來對最佳化方案把關。當然如果專案組裡有一些資深的最佳化專家坐鎮或者提供顧問支援，那也是降低項 目風險的有力保障。儘管這些專家並不是專案組的常駐成員，但是以他們的經驗往往會對最佳化計劃提出合理的建議。

在 這個階段還有一點需要注意的問題就是，我們在設計最佳化方案的時候往往過於集中在專案組內部，而忽視了外部的資源，我們提出的最佳化方案有可能對於客戶來說不 具備實施條件。老白就碰到過一個專案，由於buffer busy waits十分嚴重，導致了系統效能急劇下降，影響了業務系統。經過分析，發現問題很 明確，就是某個SQL對一張表進行了過於頻繁的掃描，導致了cache buffer chains等待十分嚴重。實際上這個問題最佳化起來也很簡單，只要 調整一些緩衝池的大小就可以了，但是由於本月已經沒有停機時間了，這個方案就無法實施，在這種情況下和應用開發廠商進行了協調，最後應用開發廠商決定把這 張表的資料直接載入到共享記憶體中，需要訪問這個資料的程式直接在應用伺服器的共享記憶體裡進行讀取，而避開了對這張表的掃描，從而解決了這個問題。

不 好的最佳化方案都有共同點，就是過於的一廂情願，而沒有充分考慮到實際情況。我也看過很多最佳化方案，其中不乏一些閉門造車的方案，提出一些不切實際的建議， 雖然從技術上來看，這些建議都很有道理，但是這些方案缺乏可操作性，因此往往很難被客戶接受。比如說，我們如果一發現CPU使用率很高，就要求客戶擴 CPU，這種最佳化方案雖然正確，但是沒有多大的價值。如果某個系統確實是除了擴容CPU，沒有其他方法了，那麼這個建議就可能是一個很好的建議。

最佳化方案完成後一定要經過評審，剛才老白所說的內部評審是第一輪的評審，而更重要的是透過客戶和開發商、整合商的評審。在評審的時候我們往往會遇到很多問題，最常見的問題包括：

l 開發商不願意修改應用，而對最佳化方案提出質疑

l 客戶的能力有限，無法區分各種意見的正確性

l 由於實施條件不具備，某些方案無法落實

在 這種情況下，就需要最佳化實施者對最佳化方案又很深入的瞭解和把握。將最佳化方案的的原理、風險、效果一一向其他人解釋，甚至必要的時候最佳化實施者還需要做出某 些承諾和保證，承擔最佳化失敗後的後果。實際上任何最佳化方案都是存在一定的風險的，但是有風險不等於該方案不具備實施的可行性，如果能夠對風險有準確的評 估，並且針對風險有合理的處理預案，那麼這個方案就是可行的。

當 最佳化方案經過評審後，我們下一步就需要針對最佳化方案設計詳細的實施方案。實際上，實施方案的編寫是最佳化成功的關鍵，實施方案將選擇我們處理問題的技術路 線，並且為每個風險設計規避方案和應急預案。在設計實施方案的時候，還需要對實施的每個步驟進行評估，確定每個步驟的實施時間，從而為合理的安排停機視窗 提供依據。如果一次試試的內容過多，無法保證在停機視窗內完成的話，我們就必須在實施方案中將這些操作分配到兩個停機視窗裡完成。

合 理的評估實施時間是十分關鍵的，老白參加過的最佳化專案中，很大比例的專案在實施時間的評估上存在不足的情況，最終導致實施的時間十分緊張，嚴重的時候甚至 可能導致專案失敗回退。而實施時間評估不足的最主要的原因是我們沒有給問題規避和回退預留足夠的時間。在設計最佳化方案和實施方案的時候，我們往往會遇到一 個問題，就是我們無法在測試環境中對我們的方案進行驗證，這往往會導致我們的最佳化方案中存在一些無法預料的問題。比如老白和老於在瀋陽這個專案的第一次實 施的時候，就碰到了調整cursor_sharing引數後部分模組無法正常執行的問題，最終導致這個最佳化操作回退，實際上在這個專案中，在碰到這個問題 之前，我們都一直很順利，原本計劃3點鐘就可以完成所有的操作的，不過這個問題出現後，我們透過近一個小時的分析，才確定是一個BUG導致，我們無法避 開。所以那次實施直到4點多才完成，基本上用完了我們預定的停機視窗。

實 施方案編寫的時候，還有一點要注意的是我們採用的技術路線，很多DBA都喜歡在自己的最佳化專案中採用一些看似很高深的技術，實際上，技術路線越大眾化，實 施的風險越小，而那些看似高深的技術，往往都帶有較大的風險。比如我們將普通錶轉分割槽表的時候，我們只是採用了最普通的技術，首先rename原來的表， 然後建立分割槽表，再把資料插回新表。這個方案看上去雖然技術含量不高，沒有使用線上表重定義等技術，但是這個方案是十分“安全”的。一旦最佳化中出現什麼問 題，只需要簡單的把原來的表rename回來，就可以實現回退了。