Oracle數(shù)據(jù)庫性能優(yōu)化實務(wù)-閂鎖及閂鎖優(yōu)化

Oracle數(shù)據(jù)庫性能優(yōu)化實務(wù)

第四講：閂鎖及閂鎖優(yōu)化主講人：白鱔Oracle的鎖第2頁應(yīng)用級鎖：應(yīng)用中對表等資源進(jìn)行鎖定，保證業(yè)務(wù)邏輯正確性數(shù)據(jù)字典鎖：OracleRDBMS內(nèi)核程序員使用的用來保證數(shù)據(jù)字典訪問邏輯正確性的鎖內(nèi)存控制鎖：用來保護(hù)Oracle內(nèi)部數(shù)據(jù)結(jié)構(gòu)的鎖（LATCH,MUTEX）應(yīng)用程序的鎖第3頁應(yīng)用程序鎖的優(yōu)化取決于應(yīng)用軟件編寫人員使用v$lock可以觀察鎖的情況（TM,TX）?/rdbms/admin/catblock.sql使用dba_waiters,dba_blockers來查找阻塞數(shù)據(jù)字典的鎖第4頁OracleRDBMS也是一個“程序”，需要通過鎖機(jī)制來保證程序的邏輯比如創(chuàng)建一張表要插入sys.tab$和sys.obj$等數(shù)據(jù)字典表類似這些操作也會在v$lock看到鎖的名字是特殊的管理共享內(nèi)存的鎖Oracle的內(nèi)存結(jié)構(gòu)也必須進(jìn)行同步互斥保護(hù)Oracle通過對訪問核心內(nèi)存結(jié)構(gòu)的代碼的執(zhí)行進(jìn)行控制來達(dá)到間接的保護(hù)核心內(nèi)存的目的每個LATCH都涉及到特定的內(nèi)核代碼要執(zhí)行某個代碼，必須先獲得相應(yīng)的LATCHOracle通過上述過程，可以保證核心內(nèi)存訪問的高效性和一致性什么是閂鎖Latch可以保證Oracle串行訪問核心內(nèi)存Latch必須十分高效Latch通過簡單的底層的技術(shù)實現(xiàn)，盡可能使用操作系統(tǒng)的底層技術(shù)Latch的申請不通過隊列機(jī)制閂鎖的使用Ifget_latch(‘latchname’,mode){--執(zhí)行某段內(nèi)核代碼

release(‘latchname’);}MUTLI-LATCHOracle對特定的內(nèi)核內(nèi)存只使用一個LATCH來保護(hù)如果某些內(nèi)核內(nèi)存太大，Oracle會分為一些子區(qū)域，每個子區(qū)域由一個LATCH來管理，比如：多個相同功能的LRULATCH用來保護(hù)多條LRU鏈多個HASHLATCH來保護(hù)多條HASH鏈一個LATCH可以保護(hù)多個內(nèi)核內(nèi)存區(qū)域，但是一個內(nèi)核內(nèi)存區(qū)域只有一個LATCHLATCH的模擬算法FunctionGet_Latch(latch_name,mode){IfModeeq‘immediate’{IfFast_Get(latch_name){returnTRUEElse{returnFALSE}}Else{IfFast_Get(latch_name){returnTRUE}Else{while(1==1){ifSpin_Get(latch_name){returnTRUE}Else{Register_Event(“l(fā)atch:$latch”)Sleep(try++)}}}}}FunctionFast_Get(latch_name){Iftry_to_get_latch(latch_name){returnTRUE}Else{returnFALSE}}FunctionSpin_Get(latch_name){fori=1to_spin_count{IfFast_Get(latch_name){returnTRUE}}}FunctionSleep(try){sleeptime=decode(try,0,0,1,10,2,20,3,~40,4,~80,...~2000)sleep(sleeptime)}LATCH相關(guān)的時間開銷三個方面消耗的時間：獲取LATCH的時間(SPIN:CPU時間,SLEEP等)持有LATCH的時間(內(nèi)核代碼:cpu時間,OS調(diào)用,鎖等待)LATCH釋放的時間(內(nèi)核代碼:cpu時間)注意的要點：spin消耗CPU資源，因此提高_(dá)spin_count會加大CPU開銷spin不產(chǎn)生等待事件sleep不消耗cpu時間，會記錄latchfree等待調(diào)整_SPIN_COUNT調(diào)整_SPIN_COUNT是十分危險的動作Oracle9iR2開始支持按照CLASS分類設(shè)置_spin_count找到閂鎖：selectlatch#fromv$latchnamewherename='cachebufferschains';altersystemset"_latch_classes"="98:0"scope=spfile;altersystemset"_latch_class_0"=1800scope=spfile;閂鎖使用的例子操作閂鎖等待其他等待CPU時間說明讀?。?0/2512)get_latch('cachebufferchains'):spin1獲得閂鎖以便于查找數(shù)據(jù)搜索bufferchain5查找所需數(shù)據(jù)db_file_sequential_read等待5正常的IO時間get_latch('cachebufferlruchains'):spin10獲取閂鎖get_latch('cachebufferlruchains'):sleep10獲取不到，休眠get_latch('cachebufferlruchains'):spin10繼續(xù)獲取get_latch('cachebufferlruchains'):sleep20再次休眠get_latch('cachebufferlruchains'):spin5獲取到閂鎖查找可用DBBUFFER3寫入數(shù)據(jù)1get_latch('cachebufferchains'):spin2獲取閂鎖以便將cache鏈入30537如何發(fā)現(xiàn)閂鎖等待v$session_wait,v$latch,v$latch_children等視圖Statspack報告/AWR報告：最好的工具OEMperformancemanagerdbconsole/ADDM第三方腳本或工具LATCH分析的主要思路理解LATCH的基本原理和算法發(fā)現(xiàn)LATCHFREE問題找出存在嚴(yán)重沖突的LATCH找出存在問題的LATCH相關(guān)的內(nèi)核對象分析為什么該閂鎖請求那么高，為什么等待時間那么長綜合系統(tǒng)和應(yīng)用情況提出優(yōu)化建議一種特殊的閂鎖-MUTEX從Oracle10.2開始使用Mutex來實現(xiàn)部分內(nèi)存的保護(hù)10.2.0.2開始CURSOR操作中替代librarycache,librarycachpinMutex用來保護(hù)內(nèi)存的訪問,保證內(nèi)存訪問的串行性和LATCH不同，一個Mutex只保護(hù)一塊內(nèi)存比LATCH開銷更小LATCH：150-200條指令MUTEX：35-40條指令對于需要保護(hù)一組內(nèi)存的情況，LATCH效率更高M(jìn)UTEX也支持OWI在不支持CAS的平臺上慎用MUTEXLATCH設(shè)置_kks_use_mutex_pin比如HP-UXPA-RISCSTATSPACK/AWR報告Statspack/AWR報告是最好的LATCH問題分析工具LatchActivityforDBLatchSleepbreakdownforDBLatchMissSourcesforDBChildLatchStatisticsDB閂鎖總體情況閂鎖休眠情況分解閂鎖問題源分析子閂鎖情況共享池相關(guān)的閂鎖共享池相關(guān)LATCH一般和共享池不足或者分析過于頻繁有關(guān)如果共享池命中率不高或者共享池使用率接近于100%使用，需要加大共享池共享池碎片問題也會加大閂鎖競爭sharedpoollibrarycachelibrarycachepinrowcacheobjectsrowcacheenqueuelatchDBCACHE相關(guān)閂鎖和LRUCHAINS或者HASHCHAINS相關(guān)cachebufferhandlescachebufferschainscachebufferslruchainmultiblockreadobjectsREDOLOG相關(guān)閂鎖REDOLOG相關(guān)閂鎖競爭一般由于以下原因：LOGBUFFER太小過于頻繁的COMMITREDOLOG的IO性能不佳LOGSWITCH過于頻繁歸檔出現(xiàn)問題或者歸檔過慢主要閂鎖RedoCopyRedo

allocation：9.2:LOG_PARALLELISM10G:_log_parallelism_maxRedowritingredoon-diskSCNSimulatorlrulatch與BUGBUG2452409/BUG5918642simulatorlrulatch閂鎖爭用十分高CPU使用率很高DBCACHE較大，并且訪問負(fù)載較大影響多個版本9.2.0.510.1.0.210.2.0.311.1.0.6解決方案9.2,10.1:STATISTICS_LEVEL=BASIC10.2:db_cache_advice=OFF其他閂鎖archivecontrol：和歸檔目錄有關(guān)processallocation：和進(jìn)程狀態(tài)修改有關(guān)，在短連接的系統(tǒng)中可能存在競爭sessionallocation：和SESSION信息修改有關(guān)sortextentpool：和硬盤排序有關(guān)childcursorhashtable：和SQL分析以及CURSORVERSION有關(guān)enqueuehashchains和鎖的管理有關(guān)modifyparametersvalues：動態(tài)調(diào)整參數(shù)有關(guān)parallelqueryallocbuffer,parallelquerystats:和并行查詢有關(guān)GES*：和全局鎖有關(guān)GCS*：和全局CACHE有關(guān)案例分析-現(xiàn)象CPU使用率突然增加系統(tǒng)變得十分緩慢procsmemorypagefaultscpurbwavmfreereatpipofrdesrinsycsussyid1763014389672355278713000008080510506161404561763014389672335712102500000106059463213381946014010145331423436315320000001094993765137589370140101453314231984107900000125341023721593792801401014533142320065540000013046105209171229370

案例分析-TOPEVENTSTop5TimedEvents~~~~~~~~~~~~~~~~~~%TotalEventWaitsTime(s)ElaTime

latchfree951,180467,35673.70CPUtime53,5598.45dbfilesequentialread9,592,36953,0128.36enqueue10,75129,5804.66dbfilescatteredread2,154,81918,0012.84

平均每次閂鎖等待時間高達(dá)481毫秒案例分析：閂鎖情況PctAvgWaitPctGetGetSlpsTimeNoWaitNoWaitLatchRequestsMiss/Miss(s)RequestsMiss

cachebufferhandles4,020,9300.10.21750cachebufferschains1,453,078,2270.10.4######58,923,93915.9cachebufferslruchain1,258,1110.60.245862,163,5503.0案例-子閂鎖情況案例分析：分析結(jié)論及采取措施故障原因應(yīng)用對幾張熱