資料庫領域尺有所短寸有所長

前陣子看到一個網友發的一個AWR報告，當時並沒有說系統存在什麼問題。也有一些朋友對此好奇，分析了一些問題。我簡單看了一下，這個系統的每秒執行數高達70萬+，CURSOR方面的爭用挺厲害的。這種負載泡在Oracle 11.2.0.4上效果還是不錯的，如果是Oracle 10.2或者更低版本,很可能資料庫的效能會更差一點。

從Load profile上我們可以看到很多資訊，首先是REDO量並不大，4.5M/秒都不到，事務數1529還是挺高的，不過事務都不大，每個事務redo 3K左右。每秒解析1.1萬+，硬解析1247。無解析執行比例還挺多，說明資料庫的一些和CURSOR相關的引數設定還是合理的。SQL也大多使用了繫結變數，並且執行計劃也相對穩定。

接下來看一下影響例項效能的一些主要的命中率指標，Parse Cpu 頭 Parse Elaspd的百分比是41.85%，對於這種解析數量比較高的系統來說，這個指標往往會偏低，這個指標越低說明解析中的等待越多。這個系統的軟解析比例不到90%，這一點在Load Profile裡已經能看出來了。Non-Parse CPU是89.85%，說明解析消耗了10%左右的CPU資源。這個指標偏低了，一般系統中都會在95%以上，不過指標異常並不一定說明存在問題，因為本系統是96核，192執行緒的四路伺服器，目前CPU還不存在瓶頸。

從sys%來看，目前系統並沒有因為閂鎖spin而引發CPU問題，因此解析對系統的影響還是有限的。

從Top 10 Events來看，DB CPU佔比達到64.8%，說明大部分CPU還是被SQL執行所佔用，也說明系統 整體狀態還不太糟糕。而與SQL 執行相關的MUTEX和閂鎖來看平均等待時間也還可以。

對於這個系統，我們下一一步要關注什麼呢?執行數量最高的SQL是需要重點關注的。可以看最排名前三的SQL，或者前五的SQL是最值得關注的。這些SQL返回的行數都不多。平均每次大概1行或者0行。這種SQL我們一般很難在AWR裡看到它出現在GETS/READS的TOP SQL裡，不過我們可以在AWR的資料表中去分析，大概每次執行的GETS有多少，再和執行時間作比較，算出CURSOR和共享池方面的併發衝突對它的執行效率有多大影響，是否需要最佳化。因為這裡缺乏資料，我就不做評價了。

從總體上來說，系統的硬體還是比較強悍的，資料庫引數設定也基本上合理。除了_cursor_features_enabled不知為何設定成了10，有可能這套系統是從10.2上升級上來的，在10.2的某些版本中 ，為了解決因為CURSOR共享而引發的某些CURSOR版本過多，從而引發大量的kksfbc child completion等待，影響併發執行的效能，會將此引數設定為10，而11g後的建議設定是不同的，11.2.0.3後這個問題需要透過將引數設定為100來解決，而不是當前系統中設定的10。

在一個 超高併發執行的場景中，經常會有一些執行效率較高的SQL，併發執行量很大，而Oracle這樣的資料庫是全域性共享SQL PLAN的，這種場景實際上對於全域性共享SQL PLAN的相同要求極高，搞得不好就會引發更為嚴重的共享池效能問題，從而讓全域性共享SQL PLAN反而變成了一個負擔。

要解決這個問題，最好不要想著直接從資料庫的角度去解決問題，共享池的很多最佳化能力有限，甚至調整得不好還會引發其他問題。因此最好的方法是儘可能減少某個library cache 物件的併發訪問次數。我們以前透過在SQL中加入隨機數註釋的方式讓同一條SQL變為多條：select /*+ cursor_x */ count(*) from ...。透過插入cursor_0,cursor_1這樣的註釋，讓這條SQL變成多個cursor，從而降低共享池熱點的爭用問題。

尺有所短，寸有所長，雖然Oracle很牛，不過這種場景，最好的方式不是由Oracle來做，而是交給redis這樣的記憶體資料庫去做。實際上前三條執行數量極高的語句都是很容易在redis中實現的。可以將資料裝載到redis中，直接透過kv的訪問去查詢，這樣效率就高多了。如果這些資料偶爾還是會修改的也不怕，變更也可以在redis中完成，定期將資料重新整理回Oracle就行了。而如果redis找不到資料再去Oracle中查詢，再同時緩衝到redis中就行了。如果redis的命中率不高，再加個布魯姆過濾器就齊活了。這些方法對大多數開發團隊來說，都是輕車熟路的事情。

在超高併發執行的場景，很多時候還是要儘可能避開資料庫的缺點。實際上共享SQL PLAN的資料庫對於存在某個熱點的超高併發執行，也是存在弱點的。很多朋友都建議國產資料庫支援全域性共享SQL PLAN，這個功能確實很有價值，但是要做好不容易。今天時間有限，就談到這裡吧，對於全域性共享SQL PLAN的話題，我們以後找時間再詳細聊聊。