有朋友和我討論根因分析的問題，他認(rèn)為大多數(shù)情況下根因分析是空中樓閣，因為數(shù)據(jù)庫的問題的根因都在數(shù)據(jù)庫產(chǎn)品的原代碼上。這個觀點有一定的道理，他所說的根因是絕對的根因，并不是日常為解決問題而去尋找的根因。這個世界上我們無法窮盡自然規(guī)律去找到最終的根因，但是我們能夠找到那個與解決問題有關(guān)的關(guān)鍵問題，我們暫且稱之為“根因”。不過當(dāng)我們對某些原理理解不夠深入和全面的時候，我們就無法找到那個解決問題的關(guān)鍵，這就是我一直堅持的那個理解數(shù)據(jù)庫的本質(zhì)的主要原因。我寫《DBA的思想天空》也是希望DBA在成長過程中多去掌握一些數(shù)據(jù)庫原理性的技術(shù)，而不是僅僅學(xué)習(xí)一些技巧。c1K28資訊網(wǎng)——每日最新資訊28at.com

有時候我們發(fā)現(xiàn)數(shù)據(jù)庫中有幾條SQL總是有點問題，而且問題出在CURSOR共享上，但是我們經(jīng)常找不出根因來。實際上共享池問題的復(fù)雜性超出了一些DBA的認(rèn)知極限，里面涉及的技術(shù)原理實在是太復(fù)雜了。c1K28資訊網(wǎng)——每日最新資訊28at.com

Oracle的CURSOR SHARING技術(shù)的關(guān)鍵部分是LIBRARY CACHE的管理。LIBRARY CACHE也是按照HASH CHAINS的方式來管理的，會被分為多個HASH BUCKET。當(dāng)要定位某條SQL的時候是通過HASH算法來快速定位的。    c1K28資訊網(wǎng)——每日最新資訊28at.com

圖片c1K28資訊網(wǎng)——每日最新資訊28at.com

首先根據(jù)SQL語句生成HASH值，然后通過HASH CHAINS找到相關(guān)的的Object Handle。對于Hash Chains，大家都不陌生，數(shù)據(jù)庫中的很多鏈表管理，都是采用HASH桶的方式管理的。對于HASH桶，大家立即就會想到均衡問題，對于CACHE BUFFER CHAINS，不均衡的HASH桶會產(chǎn)生訪問性能不佳的HOT BUFFER，而對于LIBRARY CACHE HASH BUCKETS，則會產(chǎn)生訪問延時過大的library cache handle。過于長的HASH CHAINS在數(shù)據(jù)庫中的表現(xiàn)可能會導(dǎo)致library cache閂鎖的等待出現(xiàn)異常。    c1K28資訊網(wǎng)——每日最新資訊28at.com

圖片c1K28資訊網(wǎng)——每日最新資訊28at.com

如果某個bucket上的鏈表比較長，那么如果OBJECT HANDLE在這條鏈上，相關(guān)的SQL的執(zhí)行效率就會受到一定的影響。因此一般情況下，HASH CHAIN的深度都不會太大。我們可以通過下面的命令來DUMP一下LIBRARY CACHE。用SYSDBA登錄數(shù)據(jù)庫，然后執(zhí)行：    c1K28資訊網(wǎng)——每日最新資訊28at.com

oradebug setmypid;c1K28資訊網(wǎng)——每日最新資訊28at.com

oradebug dump library_cache 2;c1K28資訊網(wǎng)——每日最新資訊28at.com

圖片c1K28資訊網(wǎng)——每日最新資訊28at.com

可以看到LIBRARY CACHE TABLE一共有131072個BUCKET，一共有52101個對象。Oracle的 library cache bucket機制是十分古老的機制，我第一次了解到這個概念是在Oracle 7上遇到的一個BUG。這個BUG讓我認(rèn)識了_KGL_BUCKET_COUNT這個隱含參數(shù)。Oracle的LIBRARY CACHE HASH BUCKET的最小數(shù)量是509。不過這個值相當(dāng)小，如果一個數(shù)據(jù)庫實例中只有這么多個BUCKET，那么一個桶上將會鏈接過多的HANDLE了。從上面DUMP的例子可以看到，13萬+的桶上有5萬多個HANDLE。c1K28資訊網(wǎng)——每日最新資訊28at.com

Oracle的算法是，當(dāng)桶上的平均深度超過2的時候，BUCKET會自動擴容一倍。當(dāng)數(shù)據(jù)庫實例啟動后，最多自動擴容7次，也就是會擴大到128倍。似乎這個算法也沒啥毛病。不過當(dāng)HASH BUCKET擴容的時候，所有的HASH鏈都要重組，這是一個十分高開銷的操作。二十多年前我就在一套ORACLE 7上遇到過這樣的問題。當(dāng)時我通過開SR知道了一個參數(shù):_kgl_bucket_count。這個隱含參數(shù)確定了當(dāng)數(shù)據(jù)庫實例啟動的時候，HASH BUCKET的數(shù)量。1代表509，2代表1021，3代表2041，都是對應(yīng)2的冪次略小的素數(shù)。以此類推，9是最大值，代表131071，可以管理131072個桶。這正好和上面DUMP的例子相吻合。    c1K28資訊網(wǎng)——每日最新資訊28at.com

圖片c1K28資訊網(wǎng)——每日最新資訊28at.com

下面我們先來刷新一下共享池，再來做一個DUMP，看看會有什么結(jié)果出現(xiàn)。c1K28資訊網(wǎng)——每日最新資訊28at.com

圖片c1K28資訊網(wǎng)——每日最新資訊28at.com

可以看出，存在較多對象的Buckets消失了。這個時候去訪問這些library cache objects，性能就不會有問題了。在大多數(shù)情況下，刷新共享池是可以解決此類library cache問題的。當(dāng)然，刷新共享池對于一些關(guān)鍵系統(tǒng)來說依然是有風(fēng)險的。因為大量的SQL會重新解析，共享池爭用會在瞬間加大，因此此類操作不能在業(yè)務(wù)高峰期執(zhí)行。另外一個風(fēng)險是重新編譯SQL可能會因為某些數(shù)據(jù)庫表和索引的統(tǒng)計信息不準(zhǔn)確而導(dǎo)致新的SQL執(zhí)行計劃變壞，引發(fā)其他的性能問題。    c1K28資訊網(wǎng)——每日最新資訊28at.com

今天我們可以學(xué)到的一個技巧就是，遇到一些無法解釋根因的SQL解析性能問題，如果只是集中在某個或者某幾個SQLID上，那么可以通過對library cache做一個 level 2的DUMP就可以分析今天所說的這個原因了。也許我們以后做數(shù)據(jù)庫巡檢的時候，也可以在非業(yè)務(wù)高峰期做一下DUMP，分析一下共享池是否存在這種風(fēng)險。c1K28資訊網(wǎng)——每日最新資訊28at.com

說到今天的這個話題，想起了20多年前的一個案例，當(dāng)時的數(shù)據(jù)庫是7.3，當(dāng)時的服務(wù)器配置都不高，SGA也比較小，因此_kgl_bucket_count默認(rèn)還是1。用戶經(jīng)常出現(xiàn)bucket擴容而引發(fā)的系統(tǒng)幾乎HANG死的情況，引起系統(tǒng)卡頓十多分鐘甚至更長。那時候這個數(shù)據(jù)庫每個月都會進行重啟維護以避免共享池 碎片嚴(yán)重而引發(fā)的嚴(yán)重系統(tǒng)問題。c1K28資訊網(wǎng)——每日最新資訊28at.com

不過自從這個制度制定后，共享池碎片導(dǎo)致ORA-4031的問題解決了。不過重啟后過一段時間就會一定出現(xiàn)一次卡頓，隨后就基本上就不再出現(xiàn)了。這個問題十分詭異，我查了很久都沒有找到問題的根因，于是只能開了SR。經(jīng)過Oracle原廠排查，定位到了這個問題 。將該參數(shù)改為2之后，就沒有出現(xiàn)過這個問題。客戶的領(lǐng)導(dǎo)也是一個技術(shù)達(dá)人，他覺得既然這個問題存在，那么把這個參數(shù)再設(shè)大一點不是更加安全。于是我?guī)退麄冋{(diào)整了參數(shù)。結(jié)局很悲催，當(dāng)時的數(shù)據(jù)庫版本中這個參數(shù)設(shè)置得過大會觸發(fā)一個BUG，高負(fù)載時引發(fā)實例宕機。這個宕機問題很難定位，過了好久才被真正定位出來。c1K28資訊網(wǎng)——每日最新資訊28at.com

本文鏈接：http://www.tebozhan.com/showinfo-26-96997-0.htmlLibrary Cache Hash Bucket與共享池閂鎖爭用問題

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： 千萬不要再用錯了這個 Lodash 方法了！可能釀成大禍！

下一篇： 掌握這四種方法，多線程按序執(zhí)行不再是問題