本節書摘來自華章計算機《Oracle數據庫性能優化方法論和最佳實踐》一書中的第2章，第2.1節，作者：柳遵梁潘敏君應以峰著，更多章節內容可以訪問云棲社區“華章計算機”公眾號查看
第2章 Oracle性能優化方法論的發展
Oracle數據庫在開發和使用過程中對數據庫的性能優化極為重視，幾乎在每個版本的更新中都會對可優化的數據庫做出改善。不僅如此，Oracle數據庫還會使用優化方法來指導性能優化，會不斷推出新的性能優化方法論，并依據優化方法論持續完善其可觀察的性能優化體系。
從Oracle 6到現在的Oracle 12c，經歷了Oracle 7、Oracle 8、Oracle 8i、Oracle 9i & R2、Oracle 10gR1 & R2、Oracle 11gR1 & R2和Oracle 12c等版本的更新。從Oracle 7開始奠定Oracle的江湖地位，Oracle 8開始超越，到Oracle 8i的大紅大紫，以及Oracle 9i以來的持續保持和發展，每個版本都有其特色和定位。在Oracle的主要發展版本中可以看到Oracle性能優化方法論的持續發展。Oracle 7中成熟的命中率分析方法，Oracle 8開始出現OWI（Oracle Wait ）的影子，到Oracle 8i，OWI開始走向前臺并快速成熟起來。由于OWI方法的簡單實用，目前它是Oracle性能優化方法論中的主流。Oracle 8i能大紅大紫應該有OWI方法的貢獻。從Oracle 8i開始，Oracle的性能優化方法論遠遠超過了其他同類的數據庫，Oracle真正成為性能優化就緒的數據庫。Oracle 9i開始出現TBA（Time Based Analyze）和基線管理，并在Oracle 10g版本中成熟，在Oracle 11g版本中持續完善。從Oracle 10g開始，Oracle認識到平均化的負面影響，使性能檢測數據的粒度越來越細致，已經可以快速發現平均化可能面臨的問題。
Oracle 11gR2中的TBA性能分析方法論還不太成熟，但是TBA方法已經在一些復雜的性能優化案例中體現出了威力。除TBA之外，Craig 提出了UOWTBA（Unit of Work Time Based Analyze）方法論，筆者認為UOWTBA是TBA方法的重大改善，可使TBA方法被真正有效地使用。本書將以UOWTBA方法為基礎，提出了基于流程、資源和組件的綜合性能優化方法論，構建了全新的Oracle數據庫性能優化的可測量體系。
2.1基于局部命中率分析的優化方法論
案例描述：某市工商局的綜合業務處理系統報告長期以來在業務忙碌的時候運行緩慢。筆者指導客戶生成AWR報告，發現Cache Hit Ratio只有72%，Top 5 wait主要為db f?ile read和db f?ile read。檢查SGA buffer cache配置，只有375MB。簡單增加buffer cache到2GB，所有性能問題都消失。
在目前，一個性能優化工作者遇到上述案例的性能優化需求，與中彩票類似，一般只有在菜鳥安裝的數據庫中才會存在。
基于命中率的分析方法是一個古老的性能優化方法論，不僅是在Oracle數據庫中，在Sybase、DB2等數據庫，甚至在任何IT設備中都存在基于命中率的分析方法。對于Oracle數據庫而言，局部命中率的分析方法基于以下樸素的觀點：如果構成系統的每個零件都表現優異，那么整個系統的表現也是優異的。當然，任何具有流程知識的人員都知道以上觀點是不可靠的。
如圖2-1所示，以我們的經驗來看，其中B路段會成為高吞吐量場景中的瓶頸，會導致整條馬路的車流不暢（那是因為有全局觀點了）。但是，如果站在B路段內部來看問題，即使在業務最高峰的時候，B路段也表現出運行非常流暢，吞吐量表現極好，也許會成為表現最好的路段（如臭名昭著的新嶺隧道，有興趣的讀者可以上網搜索一下）。基于命中率的分析方法與B路段的觀察者和管理者一樣，它只關心內部的表現或者自己的表現。
命中率的分析方法作用于性能優化，具有以下致命的缺陷。
命中率分析僅關注和作用于自身，不關心外部信息。
這里以馬路收費站作為例子，命中率分析方法僅關心通過收費站的吞吐量是否正常，而看不到等待穿過收費站的長長的隊伍。從命中率的觀點出發，只要收費站操作順利，不出現故障，即使隊伍排成10km的長龍也是性能優異的。
命中率分析方法通過全局平均化模糊了個體，而大部分性能問題都是基于個體的。
比如某個心外科手術醫生對于心臟搭橋手術的成功率為98%，每年做500例手術，但是對于那10個落在2%的病人來說成功率就不是98%，而是100%丟了性命。
盡管命中率分析方法明顯不可靠，但由于其獲取數據的成本低廉以及易于理解，也具備描述目標基本性能的能力，事實上，它已成為IT設備甚至生活中工作性能的標準描述方法。對于命中率分析方法，我們可以這樣來描述它：命中率分析結果優秀，不能保證業務系統或者數據庫具有優異的性能；命中率分析結果不好，基本可以確認業務系統或者數據庫不具備優異的性能。在Oracle性能優化中，命中率分析方法不足以成為獨立工作的方法論，但必須成為輔助分析的一部分，只有確保Oracle每一個部件自身的工作表現優異才可以使業務性能表現優異，Oracle的某個部件工作表現不正常，幾乎可以斷定業務性能不會反應良好。事實上，我們只要把視野抬高一寸，把自身部件和設備作為全局流程處理過程中的一個節點，自然就會把輸入和輸出作為衡量自身部件和設備的重要衡量因素，從而使古老的命中率分析方法依然在最新的性能優化時代發揮出其固有的作用。
命中率可以體現在不同的顆粒度上，如系統全局層、會話層、對象層和SQL層等。下面以buffer cache命中率來說明命中率分析的不同層次。
計算公式：buffer cache hit ratio = logical reads/ （logical reads + reads）
系統全局層：v$sysstat或者V$CS
會話層：v$sesstat或者v$sessio對象層；v$segstat或者v$
SQL層：v$sqlarea
具體到某session的一條SQL或某一時間段的命中率，還可以通過SQL Trace或者10046跟蹤得到，如下：
