Library Cache Hash Bucket與共享池閂鎖爭用問題
有朋友和我討論根因分析的問題，他認為大多數情況下根因分析是空中樓閣，因為數據庫的問題的根因都在數據庫產品的原代碼上。這個觀點有一定的道理，他所說的根因是絕對的根因，并不是日常為解決問題而去尋找的根因。這個世界上我們無法窮盡自然規律去找到最終的根因，但是我們能夠找到那個與解決問題有關的關鍵問題，我們暫且稱之為“根因”。不過當我們對某些原理理解不夠深入和全面的時候，我們就無法找到那個解決問題的關鍵，這就是我一直堅持的那個理解數據庫的本質的主要原因。我寫《DBA的思想天空》也是希望DBA在成長過程中多去掌握一些數據庫原理性的技術，而不是僅僅學習一些技巧。
有時候我們發現數據庫中有幾條SQL總是有點問題，而且問題出在CURSOR共享上，但是我們經常找不出根因來。實際上共享池問題的復雜性超出了一些DBA的認知極限，里面涉及的技術原理實在是太復雜了。
Oracle的CURSOR SHARING技術的關鍵部分是LIBRARY CACHE的管理。LIBRARY CACHE也是按照HASH CHAINS的方式來管理的，會被分為多個HASH BUCKET。當要定位某條SQL的時候是通過HASH算法來快速定位的。
圖片
首先根據SQL語句生成HASH值，然后通過HASH CHAINS找到相關的的Object Handle。對于Hash Chains，大家都不陌生，數據庫中的很多鏈表管理，都是采用HASH桶的方式管理的。對于HASH桶，大家立即就會想到均衡問題，對于CACHE BUFFER CHAINS，不均衡的HASH桶會產生訪問性能不佳的HOT BUFFER，而對于LIBRARY CACHE HASH BUCKETS，則會產生訪問延時過大的library cache handle。過于長的HASH CHAINS在數據庫中的表現可能會導致library cache閂鎖的等待出現異常。
圖片
如果某個bucket上的鏈表比較長，那么如果OBJECT HANDLE在這條鏈上，相關的SQL的執行效率就會受到一定的影響。因此一般情況下，HASH CHAIN的深度都不會太大。我們可以通過下面的命令來DUMP一下LIBRARY CACHE。用SYSDBA登錄數據庫，然后執行：
oradebug setmypid;
oradebug dump library_cache 2;
圖片
可以看到LIBRARY CACHE TABLE一共有131072個BUCKET，一共有52101個對象。Oracle的 library cache bucket機制是十分古老的機制，我第一次了解到這個概念是在Oracle 7上遇到的一個BUG。這個BUG讓我認識了_KGL_BUCKET_COUNT這個隱含參數。Oracle的LIBRARY CACHE HASH BUCKET的最小數量是509。不過這個值相當小，如果一個數據庫實例中只有這么多個BUCKET，那么一個桶上將會鏈接過多的HANDLE了。從上面DUMP的例子可以看到，13萬+的桶上有5萬多個HANDLE。
Oracle的算法是，當桶上的平均深度超過2的時候，BUCKET會自動擴容一倍。當數據庫實例啟動后，最多自動擴容7次，也就是會擴大到128倍。似乎這個算法也沒啥毛病。不過當HASH BUCKET擴容的時候，所有的HASH鏈都要重組，這是一個十分高開銷的操作。二十多年前我就在一套ORACLE 7上遇到過這樣的問題。當時我通過開SR知道了一個參數:_kgl_bucket_count。這個隱含參數確定了當數據庫實例啟動的時候，HASH BUCKET的數量。1代表509，2代表1021，3代表2041，都是對應2的冪次略小的素數。以此類推，9是最大值，代表131071，可以管理131072個桶。這正好和上面DUMP的例子相吻合。
圖片
下面我們先來刷新一下共享池，再來做一個DUMP，看看會有什么結果出現。
圖片
可以看出，存在較多對象的Buckets消失了。這個時候去訪問這些library cache objects，性能就不會有問題了。在大多數情況下，刷新共享池是可以解決此類library cache問題的。當然，刷新共享池對于一些關鍵系統來說依然是有風險的。因為大量的SQL會重新解析，共享池爭用會在瞬間加大，因此此類操作不能在業務高峰期執行。另外一個風險是重新編譯SQL可能會因為某些數據庫表和索引的統計信息不準確而導致新的SQL執行計劃變壞，引發其他的性能問題。
今天我們可以學到的一個技巧就是，遇到一些無法解釋根因的SQL解析性能問題，如果只是集中在某個或者某幾個SQLID上，那么可以通過對library cache做一個 level 2的DUMP就可以分析今天所說的這個原因了。也許我們以后做數據庫巡檢的時候，也可以在非業務高峰期做一下DUMP，分析一下共享池是否存在這種風險。
說到今天的這個話題，想起了20多年前的一個案例，當時的數據庫是7.3，當時的服務器配置都不高，SGA也比較小，因此_kgl_bucket_count默認還是1。用戶經常出現bucket擴容而引發的系統幾乎HANG死的情況，引起系統卡頓十多分鐘甚至更長。那時候這個數據庫每個月都會進行重啟維護以避免共享池 碎片嚴重而引發的嚴重系統問題。
不過自從這個制度制定后，共享池碎片導致ORA-4031的問題解決了。不過重啟后過一段時間就會一定出現一次卡頓，隨后就基本上就不再出現了。這個問題十分詭異，我查了很久都沒有找到問題的根因，于是只能開了SR。經過Oracle原廠排查，定位到了這個問題 。將該參數改為2之后，就沒有出現過這個問題。客戶的領導也是一個技術達人，他覺得既然這個問題存在，那么把這個參數再設大一點不是更加安全。于是我幫他們調整了參數。結局很悲催，當時的數據庫版本中這個參數設置得過大會觸發一個BUG，高負載時引發實例宕機。這個宕機問題很難定位，過了好久才被真正定位出來。
