《Oracle資料庫性能優化方法論和最佳實踐》——1.7 Oracle性能優化的神話和誤區

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

oracle性能優化工作是oracle資料庫科學最為神秘莫測的領域，自然也就會流傳着各種傳言和八卦。本書最主要的目的就是真正使oracle性能優化成為一門嚴謹的科學，使任何閱讀并且了解本書内容的讀者可以比較簡單地完成oracle性能優化工作，使自己在其他人面前成為“巫師”或“神秘的對象”。

1.7.1　藝術和科學

從百度、google等網站搜尋“性能優化藝術”，會出現大量的條目，部分oracle性能優化的圖書也是直接以“藝術”作為書名的。藝術是什麼？藝術是一種具有美感的事物，而美感的事物通常都是因人而異的，自然也就缺乏基本的衡量了。由于大部分人都不具備藝術細胞，是以藝術就成為少部分人的特權，這樣oracle性能優化也就成為少部分專家的專利。性能優化工作被表述為藝術，可能部分是因為基于資源瓶頸分析的方法論的流行，按起葫蘆浮起瓢，由于資源之間的互相瓶頸轉換，使性能優化工作有時候需要進行平衡，而平衡向來被稱之為藝術。本書希望可以打破這種專利，幫助廣大的dba和開發者以科學的觀點來看待性能優化，以科學的方法來完成性能優化，而不是依賴于靈感。

oracle性能優化要從藝術成長為科學，必須完成以下幾項基本工作：

性能優化的結果可測量、可量化。

性能優化的大量相關性可以被量化，具有相對客觀的标準。

性能優化的改善必須可測量、可量化，具有高度嚴謹性。

1.7.2　oracle業務系統性能優化是高手的專利

大量初級dba對性能優化望而卻步，甚至部分進階dba對性能優化也摸不透。事實上，性能優化是方法重于知識、經驗和技術的工作，也許正是這個原因導緻了性能優化成為難題。其實，性能優化工作者不需要精通oracle，不需要對所謂的核心做深入的研究，甚至很多場景下先後順序了解錯誤都不會影響優化工作的成效，總之不需要他有多精通oracle。性能優化工作者真正需要的是具有廣泛的知識和視野，具有全局性觀點和流程觀點，具有較好的客戶溝通能力，等等。筆者學習oracle資料庫不到1年就開始獨立做電信營業系統的綜合性大型性能優化工作，并且取得了良好的效果，筆者不認為那時候自己有很強的oracle

技術。

雖然有科學的方法和體系做引導，相比于其他工作，性能優化工作還是具有一定的特殊性，阿裡巴巴的一則招聘廣告在某種程度上反映了性能優化工作需要的素質和知識：

1.?職位描述

1）對大型網際網路應用的性能測試、分析、優化等進行研究，形成方法論、流程和自動化工具。

2）通過對os、jvm、中間件、應用等的優化，提升伺服器資源的綜合使用率。

3）根據容量情況，推進生産系統的整體優化和綜合優化，降低tco。

4）指導容量規劃和管理工作。

2.?崗位要求

1）熟悉大型分布式網站開發、性能優化或運維工作，知識面廣、綜合技能強，性能優化工作經驗優先。

2）熟悉linux os、nginx、haproxy、apache，以及java中間件應用，熟悉網絡協定。

3）掌握多種性能診斷、問題解決的技巧和思路。

4）具有良好的溝通能力和執行力，具有鑽研精神。

1.7.3　測試系統性能很好，生産系統為什麼不行

類似的描述還有“某某使用者運作得很好，為什麼在你這裡就不行？”

任何業務系統都在一個獨特的上下文中運作，業務系統運作的好壞很大程度上不是依賴于業務系統本身，而是依賴于業務系統運作上下文環境。回到前面的寶馬汽車案例，寶馬汽車開得快慢，絕大部分場景下不取決于寶馬汽車本身，而在于寶馬汽車運作的上下文環境，比如司機、天氣、路況等，時空環境決定了寶馬汽車的速度，同樣它也會決定業務系統的運作速度。

1.7.4　針對特定性能問題的标準解決方案

再次說明，性能問題總是與上下文環境相關的，自然，其解決方案也與上下文相關。比如寶馬汽車速度慢，不同的環境下需要不同的改善方式，當然也可以說，如果針對每個環境因素給出改善方案，其性能就會得到優化。不過由于環境的複雜性，現實中似乎不太可能完全做到。在業務系統中，性能問題正是在上下文複雜性這點上表現出了與故障問題截然不同的方向，故障問題絕大部分是由于資料庫本身的部件出現故障引起的，是以其解決方案通常都是一緻的，上下文很少會影響到故障的處理方法。

一個擅長處理故障的進階dba，未必就可以很好地處理性能優化問題。經驗的堆積可以造就具有相當水準的故障處理進階dba，但未必就可以造就一個具有相當水準的優化dba。掌握科學的處理方法是優化dba最為重要的課題。無法完成在方法上的突破，再多的經驗積累也不能造就一個充滿信心的優化dba。

1.7.5　隻要資源充足，資料庫性能就不會差

資源（比如cpu、記憶體、io subsystem）隻是資料庫性能表現的一個方面，比較而言，并發性或者吞吐量才是資料庫性能中更加重要的影響因素。事實上，國内企業比較喜歡硬體資源高配化，是以往往有大量的資源處于空轉狀态，性能問題會伴随着這些高配的業務系統而頻繁發生。

從另一個角度來看，對于dss或批處理系統，大量的空閑資源無法被充分利用是業務系統性能問題的一個典型特征。業務性能優化中有一句行話：沒有經過優化的系統總是傾向于i/o瓶頸，而經過優化的系統總是傾向于cpu瓶頸。這句話包含兩方面的含義。

cpu幾乎總是it業務系統中最為昂貴的部件，任何不被利用的cpu資源都會表現為極大的資源浪費。

cpu幾乎是it業務系統中唯一一個主動驅動部件，任何其他資源和部件之上的活動都來源于cpu的驅動，隻有全速的cpu運作才有可能發揮其他部件和資源的可能

作用。

1.7.6　隻要資料庫性能好，業務系統性能必然良好

對于dba來說，形成這個觀點很自然，因為每個人都把自己擅長的事情看成是最重要的，甚至是唯一的。可惜随着業務系統的複雜化，資料庫在業務系統影響鍊條中的地位會越來越低，資料庫的性能隻是業務系統性能的一個環節——一個相對重要的環節（見圖1-9），也許未來業務系統的進一步發展會導緻資料庫隻是存儲資料的最後一個環境，甚至不會對使用者互動響應産生直接影響，那時資料庫對于業務系統性能就是一個無關緊要的環節。

1.7.7　降低等待時間就可以提高業務系統性能

oracle wait interface（owi）方法是如此之有效，因而有廣大的使用者，尤其是其類似于故障排除的思維方式，更是在dba中成為金科玉律。owi對于大部分dba來說是一個福音，使其不需要去關心真正的性能優化科學方法論，就可以延用故障排除的思路來完成性能優化，不斷積累的性能優化場景可以在owi方法中獲得價值的最大化。

因為response time = service time + queue time，是以owi方法的擁護者認為隻要降低queue time就可以提高業務系統性能。這個觀點在吞吐量壓力達到一定程度的業務系統中具有相當的正确性，不過并不是真理。采用owi方法的使用者必須要注意方法适用的場景，不要越界。owi方法在面臨下面的場景時将不再适用：

在低吞吐量的系統中，因為在此系統中很難觀察到所謂的等待。

當oracle等待時間目前無法評估cpu queue時間，而是簡單地标記為cpu時間時。

當oracle等待時間目前無法評估無效的cpu操作，比如latch spin和mutex spin操作，這些操作都被評估為cpu時間而不是等待時間時。

下面來看一個簡單的queue time和latch/mutex事件示例。

某業務系統性能響應緩慢，表現為大量cache buffer chain latch wait。有相當多的性能優化者把增加spin count作為優化的首選措施。但spin操作并非是有效的操作，它僅僅是将标記為wait的時間轉移到了cpu的消耗中，變成了service time。這個參數增加之後，很多性能優化者會發現latch等待時間減少了甚至不見了，但是業務系統性能并沒有改善。

再次看一下公式：response time = service time + queue time。增加spin count的結果就是：queue time大幅度減少，service time增加（甚至是不成比例的增加）。當然，相當多的性能優化者發現增加這個參數确實能改善性能，甚至會把這種改善方法作為一種靈丹妙藥，進而用來優化讓人讨厭的latch等待時間。不幸的是，在很多場景下增加這個參數的效果并不好，甚至可能會使性能問題進一步惡化。spin count的唯一作用在于壓榨cpu的使用，在cpu有一定空閑的前提下，spin count的增加常會帶來好處。但實際情況是，若真正有大面積的latch等待事件，那麼cpu資源往往是同步緊張的，這種情況下增加spin count通常會帶來反作用，也許正确的做法可能是降低spin count，釋放cpu資源在latch上的占用。