本節書摘來自華章計算機《oracle資料庫性能優化方法論和最佳實踐》一書中的第1章，第1.6節，作者：柳遵梁 潘敏君 應以峰著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
1.6.1 基準點和基線
人們在談論oracle業務系統的性能時通常會說它運作得快或慢，但大家都知道快和慢沒有一個絕對的标準，所有的快或慢都是基于比較而言的。比如我們在操場上15s跑完100m，沒有人會覺得你跑得快，因為大家都有一個比較的基準，大部分人都可以在12～15s跑完。同樣是100m，如果你是上樓梯，那大家可能會覺得你的速度太驚人了。是以，快慢好壞都是基于比較而言的，沒有比較就沒有性能的好和壞。是以，為了使性能優化工作更加科學，需要建立量化的性能基準點，而不能依賴于經驗來建立，畢竟經驗很難放之四海而皆準，每次衡量快或者慢的時候都可以與這個基準點進行比較，這個基準點即為基線。在oracle資料庫中，同樣需要建立基準點或者基線，用來描述oracle業務系統在某個特定的狀态下，特定的輸入響應和輸出響應以及相應提供服務的各個資源群組件狀況。當後續的業務營運和基線産生預料之外的偏離時，則表示業務系統發生了變化，不管是否會産生業務系統性能問題，都需要運維人員介入。
業務運作的狀态可能在不同的時間點表現出完全不同的業務特征，在不同的業務特征之間進行比較是沒有任何意義的。這時應該建立多個基準點來完整地描述業務系統的運作特征。比如電信計費系統在白天和晚上、月底和月初都會表現出不同的特征，是以就需要對不同時間點都建立相應的基準點或基線。
下面通過一個簡單的例子來說明基線之于性能優化的重要性。
某業務系統的性能最近變得很差，需要進行性能優化。性能優化專家發現一個明顯的現象——cpu使用率達到100%，幾乎沒有空閑時間。依據經驗，該專家認為這個100%的cpu使用率是屬于一個壞名額，并且認為這是其根本原因。通過艱苦的優化工作，cpu使用率有所下降，但是性能并沒有提高，可以想象，應該是專家找錯了方向。事實上，這個系統自上線以來其cpu一直工作在100%狀态下，且運作良好。在這種情況下，如果有了cpu的使用率基線，專家就不會犯這個錯誤，可以正确地把握方向。而且，如果進一步測量名額可以發現，雖然cpu使用率為100%，但是其服務能力沒有任何問題，并且沒有在cpu上形成大規模沖突導緻其單次服務能力下降。
基線的存在可以大大減輕性能優化者的負擔，基線的存在可以使性能優化不再是高手的專利，普通的性能優化工作者甚至是缺乏任何資料庫知識的人都可以輕松地發現導緻業務系統性能變差的原因：隻要把每個可測量的名額值和該名額的基線值進行比較，出現大規模偏差的一般就是性能問題的根源所在。
1.6.2 溝通基線
除了完全量化的基線以外，為了更好地描述業務系統的運作和性能，最好另外再建立一個相對感性的基線，即溝通基線。利用這個溝通基線與業務人員進行友好的溝通，可以更好地把握未來業務系統問題的實質。
感性溝通基線以吞吐量和響應時間為基礎對目标系統進行業務性能上的描述。溝通基線最重要的目的是确定業務的變化，相當多的性能問題是由于業務變化及其他各種相關的變化引起的。溝通基線可以從三個方面進行描述：性能感受、運作使用者、運作業務。
比如下面是一個溝通基線的簡單描述。
性能感受：基本不會出現“客戶在等、我也在等”的情況，1～2s響應，大部分情況下應該在1s左右，個别時候會有2s，因其偶爾出現，是以在可接受範圍内。存盤時會産生列印憑單，由于憑單列印機的速度通常是比較慢的，是以對列印的快慢不會有太大的感覺。為了加快業務辦理速度，往往是那邊在列印憑單，這裡就開始接受新的業務。存盤慢不要緊，但不能影響新工作的開始。
運作使用者：早上8:00到位，8:15左右正式工作，有4500～5000個人在做同樣的工作。若無特殊情況，一旦開始工作就要到中午吃飯才會退出系統，下午13:00又開始工作，17:30開始陸續下班，依據忙碌程度會延遲到20:00，但一般20:00之後就不會再做事情。
運作業務：主要是辦理受理、變更、繳費等業務，都是面向客戶互動的。
1.6.3 基線管理和動态基線
1.?基線更新和動态基線管理
随着時間的推移，業務系統會不斷發生變化，甚至硬體系統資源也會發生變化，這時基線必須同樣随之發生變化，否則就無法表述目前業務的運作狀态，進而使性能優化走向歧途。任何一個oracle業務系統性能優化體系，都應該具有通過很簡單的方式來進行多基線管理和目前基線确定的能力。
同樣，随着時間的推移，我們對性能優化的認知也在不斷提高，可能需要增加新的基線名額來更好地管理性能，作為基線管理，自然也需要支援可以簡單增加名額到基線名額管理資料庫中。
為了降低基線更新成本，可以采用動态基線，也就是讓運維管理系統自動建立基線。作為一個描述業務系統正常運作的基線資料，其重大的挑戰是必須可以自動判斷業務系統是否處在正常的運作範疇之内。不僅如此，當采用動态基線的時候，如果總是與最新建立的基線做比較，可能會出現溫水煮青蛙的情況，進而使性能監視系統失去作用。動态基線最好采用滑動視窗的形式來管理。
假設表1-6給出了基線更新情況，3月4日建立了基線Ⅰ，3月11日建立了基線Ⅱ。若基線是采用靜态基線确立的，則3月12日的基線比較會建立在3月11日的基線基礎上，因為這個基線是運維管理人員确認的業務特征基線。但是，當3月11日的基線是由系統動态建立的，那可能會存在一定問題，此時若3月12日的業務系統仍以3月11日的作為比較對象，而大部分系統的業務是随着時間逐漸增加的，這樣一來，3月12日可能無法從與3月11日的基線比較中回報出業務系統的變化，進而使業務系統的性能監視失去最佳幹預點。
假設采用動态基線管理，也許更好的方式為不管是否具有目前的更新基線，總是與滑動視窗對應的基線比較，或者總是延後生成動态基線，也會更加有利于性能資料的測量和
監視。
2.?多版本基線之間的比較
随着時間的推移，會不斷建立新的基線，這些不同版本的基線對于使用者把握業務系統的運作發展具有重要意義。我們在回顧過去一段時間業務系統運作的狀态時，基線之間的資料比較是最為便捷也是最具有價值的内容。
3.?基線資料的内容
從基線資料的性質來看，所有可測量的資料都可以成為基線資料。當然，為了讓基線更加容易管理，需要對基線名額進行分類和分組，進而更好地支援業務性能監視和業務系統性能優化。
可從吞吐量和響應時間的關系曲線（見圖1-1）來建構oracle業務性能的可測量體系，并在這個基礎上建立可比較的運作基線。本書的主要目的就是在于建立體系化的oracle業務性能可測量體系，進而支撐oracle業務系統性能優化方法論：基于流程、資源群組件分析的性能優化。
在建立了完整的可測量oracle業務系統名額體系、為可測量的名額建立了基線資料庫、确立了基于變化的性能優化診斷理論後，性能優化診斷操作就成為水到渠成的事情，而通過可測量名額的相關性分析就可以輕松地對性能進行改善，進而完成性能優化工作。
下面采用最簡單的模型公式來進行基于變化的性能優化實踐，公式如下：
吞吐量=（60/響應時間）×并發session數量
響應時間= 服務處理時間 + 服務排隊（等待）時間
服務處理時間= 單元服務次數×單元服務時間
服務等待時間= 單元服務次數×單元服務等待時間
= i/o等待次數× i/o等待時間 + 并發性等待次數×并發性等待時間
+ 其他等待次數×其他等待時間
下面來看表1-7中的兩組資料，檢視導緻性能異常的原因在哪裡。
通過對以上可測量名額進行簡單的比較可以發現：響應時間增加了，并發數增加了，吞吐量下降了。進一步比較可以發現，響應時間增加的主要原因為單元服務等待時間從220ms增加到了1516ms，變化幅度比較大，單元服務時間從410ms增加到了505ms，略有增加。而單元服務等待時間的增加主要是由單元i/o等待時間的變化引起的，它從2ms增加到了20ms。通過與基線名額資料的變化進行比較可以很簡單地做出診斷：i/o子系統出現問題導緻響應時間增加，如果了解i/o子系統的相關知識，那麼可以知道，20ms的響應時間隻有兩種可能性：
i/o嚴重堵塞。
i/o子系統出現故障類事件（配置或其他）。
從i/o發生的次數可以知道，嚴重堵塞的可能性不大（并非絕對沒有，比如資料庫外的很多負載可能導緻堵塞），是以優化調整的方向就可定為i/o子系統故障，進而檢查其配置和狀态，檢查其i/o子系統的組成鍊路等。
這時還可以進一步檢測磁盤系統的基線：
磁盤使用率= 98%
iops = 3600
服務響應時間= 2ms
從iops和2ms響應時間可以确定，目前20ms的響應時間是由i/o子系統故障引起的，可以尋求存儲廠商的介入以最終解決在存儲軟硬體層面的問題。
在筆者團隊的性能優化實踐中，類似于上面的案例幾乎每年都會發生好幾起。各位讀者可以想象一下，如果缺乏基線資料，可能就會有相當多的優化工作者（你是如何處理的呢？）通過調整sql語句來降低i/o數量，進而達成本次優化，性能優化工作最終會大部分完全失敗或部分失敗。