《Oracle資料庫性能優化方法論和最佳實踐》——1.4 Oracle性能優化工作的分類

本節書摘來自華章計算機《oracle資料庫性能優化方法論和最佳實踐》一書中的第1章，第1.4節，作者：柳遵梁　潘敏君　應以峰著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視

在oracle上進行性能優化時，不同場景下的優化工作方法和内容有很大的不同。下面從實踐角度來展開優化工作的分類。

1.4.1　上線優化或從未達到過性能期望的系統優化

如果業務系統未進行充分的性能測試就上線，那麼有相當一部分會出現性能問題，不會出現性能問題的系統往往建立在有強大硬體的基礎之上。這類缺乏性能設計考慮的業務系統部分或全部具有以下特點。

開發人員（業務系統）假設資源是無限的，可以任意使用，忘記了任何系統都是在一個資源受限的系統中運作業務。

開發人員（業務系統）認為隻有我一個人在做事，忘記了同時會有很多人在使用，缺乏并發性方面的考慮。

開發人員（業務系統）認為程式在任何時候的處理效率都是一樣的，不應該出現大的波動，不應該出現異常。

各種任務排程頻率遠遠超過業務實際需要。

sql語句消耗了無限的資源。

無法充分利用資源，缺乏并行處理或異步處理的能力。

缺乏有效的索引設計，業務系統并發能力低下。

具有很長的同步處理鍊條，性能表現極其脆弱。

運作在預設的完全不比對實體資源的資料庫上。

上線優化的場景有些比較簡單，有些會很複雜。也許你的運氣足夠好，僅僅是簡單的資料庫配置問題或作業系統配置問題，這在dba力量比較弱的開發商中存在。更多時候，你遇到的會是索引優化問題或sql優化問題，當然，隻要你願意付出精力，總能完成這類任務。如果你運氣不好，遇到除此之外的複雜性能優化問題，就需要你擁有更多的知識和經驗，以及更好的協調和溝通能力了。

1.4.2　響應速度逐漸變慢的系統優化

在業務正常運作了一段時間或很長時間之後，可能會感覺到業務系統在漸漸地變慢，甚至到了不可忍受的地步，而這是oracle資料庫，或者不僅是它，也是任何it裝置、任何提供服務的物品以及生命體（包括人動物和植物）都會展現出的特征。這時我們需要對其進行保養、修理或優化。一般來說，這類系統具有以下部分或者全部的特征：

随着時間的推移，資料量漸漸變大，而業務系統和資料量具有比較強的線性關系設計。

随着時間的推移，業務在發展，公司在變大，而業務系統和業務及資源具有較強的線性關系。

随着時間的推移，通路量在增大，而業務系統在并發性上的設計考慮不夠。

随着時間的推移，資料不斷被分享使用，不同業務之間出現并發性和資源上的碰撞。

當然，可能還存在其他的時間堆積，但是主要為以上變化度量。既然業務系統性能是一個逐漸變化的過程，那麼隻要記錄相關名額的長時間關系，自然就可以知道為什麼性能會變差，甚至可以簡單掌握哪些因子的線性關系比較重大，進而可以通過打破這個線性關系或降低線性斜率來進行性能優化，使業務系統恢複正常運作。

1.4.3　運作過程中突然變慢的系統優化

在oracle中，除了系統bug外，沒有無緣無故的性能問題。即使是oracle bug，也是因為變化引起了bug而被觸發。對這類問題的優化相對比較簡單，隻要簡單檢測突然變化即可。即使不知道為什麼，隻要把變化恢複原狀，一般業務系統就可以恢複。當然，對于這類業務系統的性能故障，使用者的緊迫度也往往比較高。

應急性性能優化是日常運作中針對業務系統的最為常見的優化工作，類似于故障處理場景。由于owi方法所具有的實時針對性，是以它在這類優化中被廣泛利用，并且效果良好。隻要日常收集關鍵名額及版本變化，通常都能較為快速地完成應急性優化。

從變化的角度來看，一般存在以下幾種情況。

新的業務子產品上線或進行了更新檔修複。

sql語句執行計劃發生變化。

ddl操作導緻sql依賴對象發生變化。

意外的配置變化。

依賴資源發生故障或性能降低，導緻吞吐量下跌。

執行了某個意外操作。

某關鍵程序挂住或死掉。

1.4.4　突然變慢，持續一段時間後又恢複正常的業務系統優化

本書介紹的發生的現象雖然與1.4.3節介紹的類似，但其形成原因往往不同。這種業務系統性能降低的場景通常是周期性發作，維持時間從幾秒、幾分到幾小時不等。一般來說，發生原因為應用系統無法度過業務高峰期，達到了吞吐量限制。

針對達到吞吐量限制的業務性能進行優化時，優化者需要通曉吞吐量與響應時間的關系曲線，了解各種資源的最大吞吐量或能力限制。擴容往往是針對吞吐量限制型優化最為直接的建議，但由于涉及額外投資且需要持續較長時間，是以性能優化者必須有充分的理由來支援擴容，并且要100%保證擴容後可以滿足業務性能的要求。擴容是通過擴充資源來支援更高的吞吐量突變點，進而完成業務性能的改善。與擴容相對應的另一種方式自然是更加有效地利用資源：降低機關操作數量或降低機關操作消耗的資源。

1.4.5　基于降低資源消耗的系統優化

事實上，當針對實際的業務系統進行性能優化時，你會發現有相當一部分并未觀察到明顯的吞吐量或未觀察到響應時間的異常，而僅僅是資源消耗達到了非預期值。對于這類問題，可用于優化的時間會相對充裕，優化操作也比較簡單，隻要簡單分析特定資源的影響因子，并從大到小進行排序，逐漸優化或隻優化影響大的影響因子即可。

1.4.6　預防性日常性能優化

基于降低資源消耗的系統優化應該是預防性日常性能優化的一個變種。預防性日常性能優化依賴于日常監測的性能因子，當這些性能因子達到預先設定的警戒值時就會進行優化，使其回歸到正常範圍或減緩其增加速度。想要保證一個系統始終保持高性能的運作，預防性的日常性能優化是關鍵因子，甚至比一種性能設計還重要。作為一個性能優化工作者或運維dba來說，雖然業務系統的性能設計不由他控制，但是盡可能地延緩業務系統性能問題的來臨是完全可以的。

預防性優化的作用主要在于：首先，延緩業務系統的硬體擴容，延遲資金投入；其次，可以使使用者對未來性能預期有一定的明确性，進而可以合理安排擴容采購視窗，避免業務系統出現性能問題，提高服務品質。而缺乏預防性優化意識往往意味着一段時間内糟糕的業務系統性能表現以及硬體擴容的緊急采購。若業務系統預防性的日常性能優化做到位，則具備圖1-8所示的特征，再次回到吞吐量和響應時間曲線。

預防性性能優化的目的在于不斷延緩突變點，使其後移，如圖1-8中使突變點從1100左右轉移到1380左右，使業務系統可以支援的最大吞吐量不斷增加。雖然任何硬體平台和軟體平台都會有其自身的吞吐量限制，但預防性維護可通過延遲硬體采購來節省大量的金錢，真正展現出性能優化的價值。

下面來做一個簡單的計算。

一個價值500萬元的硬體平台，假設将其擴容要求延遲了一年的時間，是以節約了100萬元，這代表我們并不是僅僅多獲得了1年時間的100萬現金使用權，更重要的是這一年時間裡硬體的價格會快速下跌，相比1年前，100萬元具有更高的使用價值。特别是如果到了知識産權嚴格保護的年代，硬體的擴容往往意味着軟體license授權費用的大幅度增加，這時預防性性能優化的價值幾乎是不可估量的。