《Oracle資料庫性能優化方法論和最佳實踐》——1.5 測量和變化

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

1.5.1　測量和性能

沒有測量就沒有性能，任何科學都建立在可測量的基礎之上。oracle資料庫和基于它的性能優化理所當然是一門科學，而不是一門藝術。科學的性能優化首先必須是可以建立測量的目标系統性能名額。一個無法測量的系統或者一個隻能依賴于人的眼睛、耳朵等器官來進行感覺的系統是無法進行性能優化的。為了完成性能優化，需要做大量的可測量性工作。幸運的是，oracle對于可測量的性能付出了巨大的努力，使其性能相關的測量名額遠遠超出了其他資料庫。

從性能優化的角度出發，可以從以下幾方面來建立性能優化測量名額體系。

流程：指從發指令給資料庫，到資料庫傳回我們需要的結果的整個業務處理流程。

資源：指在業務處理流程過程中需要使用的軟硬體資源，比如cpu、記憶體等。

元件：在流程進行中涉及的處理單元，比如buffer cache等。

流程是業務使用者可直接感受的性能名額，與人的感官感覺緊密相連，性能優化的根本目标就是使業務流程順利運轉。建構性能優化可測量體系的一個簡便方法是從頂層目标出發，進行分解和推導，發現其測量因子之間的依賴性、相關性和影響性。在建構此體系的過程中，若把oracle資料庫及業務流程中涉及的所有元件和資源都作為一個裝置或服務來看，則會有相當的便利，更具有真實性。

在業務流程中，當把資源群組件統一作為一個服務中心看待時，也可由此構造出統一的可測量名額體系，如下：

輸入型名額；

輸出型名額；

狀态型名額。

通過上述測量名額一起作用建構出oracle資料庫的監控體系後，即可檢測oracle業務流程是否正常運轉。除此之外，為了更快地完成性能優化，還應該力求在可測量名額之間建立關聯，比如依賴性名額、相關性名額、影響性名額等。這樣就可以通過名額相關性驅動最終發現真正導緻性能變化的名額，并且采取措施糾正它。

再次檢視吞吐量和響應時間的關系曲線，明顯可以看到，響應時間是流程的輸出結果，而吞吐量則是流程的輸入元素。

下面來看一個簡單的概念性示例。

假設系統業務為tpcc測試的訂單業務，采用訂單數量作為吞吐量輸入名額。

吞吐量（輸入型名額）=每分鐘完成的訂單數。

吞吐量（輸入型名額）=（60/每個訂單的響應時間）×并行處理會話

這裡并不是在念繞密碼，同一個名額采用不同的計算方式在性能優化分析中具有重大意義，它可以讓你清晰地了解名額之間的關系，進而采取正确的優化方式。

根據上面變種的吞吐量公式，可以認為以下兩個結論是正确的。

在并行處理會話确定的前提下，降低每個訂單的響應時間可以提高吞吐量。

在每個訂單的響應時間确定的情況下，增加并行處理會話可以提高吞吐量。

有足夠經驗的dba都知道，上面的結論完全是理論推導。在實際的環境中，若遇到吞吐量下降的場景，且每個訂單的響應時間延長，那麼總是可以觀察到并行會話的數量增加。甚至可以認為，在業務量變化不大的前提下，并行會話的增加必然意味着吞吐量的下降，而這正是訂單的響應時間的延長導緻并行處理會話增加而引起的。

在業務變化不大的前提下，從以上分析可以得出如下結論：

訂單的響應時間延長會導緻吞吐量下降。

訂單的響應時間延長會導緻并行處理會話增加。

并行處理會話的增加和吞吐量降低具有相關關系。

為什麼要這樣來描述？原因很簡單，因為每個訂單的響應時間是相對難以測量的名額，而并行處理會話極其容易被測量。

訂單的響應時間 =訂單的處理時間+訂單的等待時間

對于訂單的處理時間和訂單的等待時間，oracle都在系統級别做出了很好的測量。

假設圖1-8所示的曲線圖中那兩個圓點是響應時間和吞吐量的最佳平衡點，且在這個平衡點上有服務時間和排隊時間，當具體的訂單運作點落到平衡點的右邊或者上邊的時候就意味着出現了性能問題。每次訂單處理都由一系列的衆多過程組成，每次訂單的處理時間和排隊時間自然也由一系列衆多過程的處理之和構成，可以用以下公式來表達：

訂單的處理時間=處理次數1×每次處理時間1 +處理次數2×每次處理時間2 + ……

訂單的排隊時間=排隊次數1×每次排隊時間1 + 排隊次數2×每次排隊時間2 + ……

當處理次數發生明顯變化時，意味着業務特征或通路特征發生了變化。對于任何性能優化dba來說，這都是一個與性能相關的直接要素。而對于每次處理時間，從oracle資料庫的描述中可以看到，服務處理是由cpu來執行的，正常情況下應該保持穩定，一旦其發生明顯變化，就意味着cpu無法提供足夠的能力。

排隊次數同處理次數一樣代表着業務特征或通路特征，排隊時間則表示通路能力。應該說，oracle資料庫系統的性能優化工作者是極其幸運的，響應時間的分解幾乎都可以直接或間接通過測量獲得，這就使得oracle資料庫系統成為一個優化就緒的資料庫系統。oracle資料庫不僅具有大量的狀态型名額，還具有豐富的輸入和輸出名額。oracle資料庫不僅關系自身的零部件是否運作正常，而且關心業務操作和流程運作是否正常，也正因為如此，它使得所有這些東西都可以被直接或者間接測量。

在筆者看來，也許隻有oracle資料庫才是性能優化就緒的資料庫。

1.5.2　變化檢測和性能優化

1.4節中有介紹，除了從來未達到性能期望的業務系統的優化工作未涉及變化以外，其他都會涉及變化。可以這麼說，沒有無緣無故的性能問題，任何性能問題都是由變化引起的，包括業務量的變化、通路量的變化、并發量的變化、資料量的變化、資料結構的變化、代碼的變化等，任何交易都是建立在一定的上下文環境中的，當上下文環境發生變化的時候，其交易性能必然也發生變化。相信大部分人都明白，雖然知道性能問題是由于變化引起的，但關鍵是我們不知道哪些發生了變化，不能在性能出現問題的時候大聲地質問：導緻性能變異的變化給我站出來。大家知道，即使在現實生活中，某個人做了一些事情導緻了嚴重的事件發生，他在多數情況下也會躲起來，甚至會故意混淆視聽，告訴你是某某人做的，這也是我們這個世界需要警察的原因之一。

性能異常是由于某種或多種變化引起的，這個觀點再怎麼強調都不過分，甚至可以說本書就是圍繞這個觀點展開的。一旦确定了這個觀點，性能優化的工作難度将大幅度下降，我們的任務也就變成了确定影響性能的因子。當性能異常的時候，隻要檢測這些性能因子的變化，就可以找到性能異常的原因，知道了原因就可以采取措施進行改善。幸運的是，oracle資料庫在這方面表現得如此出色，它提供了大量的性能檢測因子，并且提供了不同時間度量的檢測手段，使oracle資料庫的性能優化工作顯得比較輕松。在後續的章節中，将陸續涉及這些性能檢測因子，本書主要圍繞這些性能檢測因子來進行性能問題的診斷和優化。

1.5.3　量變和質變

在這個世界，隻有變化是永恒的。在強調變化引起性能異常的觀點時，我們也必須認識到，并不是任何變化都會引起性能異常，量變引起質變是一個樸素的變化觀點，也完全适用于性能優化，隻有變化積累到一定程度之後才會引起性能異常。

回頭看看圖1-1會發現，響應時間隻有在達到一定的壓力突變點之後才會發生變異。

任何人和裝置、任何資源都有其處理能力的上限，當然也包括資料庫，某些裝置或某些資源還有一些突變點，當達到或即将達到處理能力的上限（或突變點）時，就會發生性能異常。

列舉兩個例子來看看個體的變化會引起什麼樣的局部變化，如下：

表格的資料增加，會使得全表掃描的響應時間随之線性增加。

索引的資料持續增加，使得唯一索引分類的層數增加，進而提高通路成本。比如從2層索引樹增加為3層索引樹，那麼唯一索引通路的成本将增加50%，響應時間将增加50%。

再來看看個體變化給全局帶來的影響，以表格資料增加10%的全表掃描為例。

變化之前業務通路時間為1s，可以接受的通路時間為2s，完全在服務品質保證範圍之内。變化之後的業務通路時間為1 + 1×10% = 1.1s，仍然在服務品質保障範圍之内。也就是從個體來說，完全沒有問題，但是從全局來說，可能就會帶來全局業務的性能急劇惡化。假設在變化之前有4個相同業務在部分時間會交疊執行，大緻會消耗大約400mb/s的i/o吞吐量帶寬，基本使i/o子系統處于臨界狀态。當每個業務的通路時間從1s延遲到1.1s時，就有可能會導緻5個甚至6個相同的業務在部分時段交疊執行，而這又會導緻超過i/o子系統的服務能力，進而使其響應時間大幅度增加。這時，業務通路最終得到的也許并不是可以接受的1.1s，而是完全不可接受的5s甚至10s的響應時間。