1、Oracle數(shù)據(jù)庫性能優(yōu)化實務(wù)第四講：閂鎖及閂鎖優(yōu)化主講人：白鱔Oracle的的鎖第2頁應(yīng)用級鎖鎖：應(yīng)用用中對表表等資源源進(jìn)行鎖鎖定，保保證業(yè)務(wù)務(wù)邏輯正正確性數(shù)據(jù)字典典鎖：OracleRDBMS內(nèi)內(nèi)核程序序員使用用的用來來保證數(shù)數(shù)據(jù)字典典訪問邏邏輯正確確性的鎖鎖內(nèi)存控制制鎖：用用來保護(hù)護(hù)Oracle內(nèi)部數(shù)數(shù)據(jù)結(jié)構(gòu)構(gòu)的鎖（LATCH,MUTEX）應(yīng)用程序序的鎖第3頁應(yīng)用程序序鎖的優(yōu)優(yōu)化取決決于應(yīng)用用軟件編編寫人員員使用v$lock可以以觀察鎖鎖的情況況（TM,TX）?/rdbms/admin/catblock.sql使用dba_waiters,dba_blockers來查查找阻塞塞數(shù)據(jù)字典典的鎖

2、第4頁OracleRDBMS也也是一個個“程序序”，需需要通過過鎖機制制來保證證程序的的邏輯比如創(chuàng)建建一張表表要插入入sys.tab$和和sys.obj$等等數(shù)據(jù)字字典表類似這些些操作也也會在v$lock看看到鎖的名字字是特殊殊的管理共享享內(nèi)存的的鎖Oracle的的內(nèi)存結(jié)結(jié)構(gòu)也必必須進(jìn)行行同步互互斥保護(hù)護(hù)Oracle通通過對訪訪問核心心內(nèi)存結(jié)結(jié)構(gòu)的代代碼的執(zhí)執(zhí)行進(jìn)行行控制來來達(dá)到間間接的保保護(hù)核心心內(nèi)存的的目的每個LATCH都涉及及到特定定的內(nèi)核核代碼要執(zhí)行某某個代碼碼，必須須先獲得得相應(yīng)的的LATCHOracle通通過上述述過程，可以保保證核心心內(nèi)存訪訪問的高高效性和和一致性性什么是閂閂鎖L

3、atch可以以保證Oracle串串行訪問問核心內(nèi)內(nèi)存Latch必須須十分高高效Latch通過過簡單的的底層的的技術(shù)實實現(xiàn)，盡盡可能使使用操作作系統(tǒng)的的底層技技術(shù)Latch的申申請不通通過隊列列機制閂鎖的使使用Ifget_latch(latch name,mode)-執(zhí)行行某段內(nèi)內(nèi)核代碼碼release(latchname);MUTLI-LATCHOracle對對特定的的內(nèi)核內(nèi)內(nèi)存只使使用一個個LATCH來來保護(hù)如果某些些內(nèi)核內(nèi)內(nèi)存太大大，Oracle會分分為一些些子區(qū)域域，每個個子區(qū)域域由一個個LATCH來來管理，比如：多個相同同功能的的LRU LATCH用來保保護(hù)多條條LRU鏈多個HASHL

4、ATCH來來保護(hù)多多條HASH鏈鏈一個LATCH可以保保護(hù)多個個內(nèi)核內(nèi)內(nèi)存區(qū)域域，但是是一個內(nèi)內(nèi)核內(nèi)存存區(qū)域只只有一個個LATCHLATCH的模模擬算法法FunctionGet_Latch(latch_name,mode)IfMode eq immediate IfFast_Get(latch_name)returnTRUEElse returnFALSEElse IfFast_Get(latch_name)returnTRUEElse while( 1=1)ifSpin_Get(latch_name)returnTRUEElse Register_Event(“l(fā)atch: $latch”)

5、Sleep(try+) FunctionFast_Get(latch_name)Iftry_to_get_latch(latch_name)returnTRUEElse returnFALSEFunctionSpin_Get(latch_name)fori= 1to_spin_countIfFast_Get(latch_name)returnTRUEFunctionSleep(try)sleeptime=decode(try,0,0,1,10,2,20,3,40,4,80,.2000)sleep(sleeptime)LATCH相關(guān)關(guān)的時間間開銷三個方面面消耗的的時間：獲取LATCH的時間間(S

6、PIN:CPU時間,SLEEP等等)持有LATCH的時間間(內(nèi)核核代碼:cpu時間,OS調(diào)調(diào)用,鎖鎖等待)LATCH釋放放的時間間(內(nèi)核核代碼:cpu時間)注意的要要點：spin消耗CPU資資源，因因此提高高_(dá)spin_count會會加大CPU開開銷spin不產(chǎn)生生等待事事件sleep不消消耗cpu時間間，會記記錄latch free等等待調(diào)整_SPIN_COUNT調(diào)整_SPIN_COUNT是十分分危險的的動作Oracle9iR2開開始支持持按照CLASS分類類設(shè)置_spin_count找到閂鎖鎖：selectlatch# fromv$latchnamewherename=cachebuffe

7、rschains;altersystemset _latch_classes=98:0scope=spfile;altersystemset _latch_class_0=1800scope=spfile;閂鎖使用用的例子子操作閂鎖等待其他等待CPU 時間說明讀?。?0/2512)get_latch(cache buffer chains):spin1獲得閂鎖以便于查找數(shù)據(jù)搜索 buffer chain5查找所需數(shù)據(jù)db_file_sequential_read等待5正常的IO時間get_latch(cache buffer lru chains):spin10獲取閂鎖get_latch(ca

8、che buffer lru chains):sleep10獲取不到，休眠get_latch(cache buffer lru chains):spin10繼續(xù)獲取get_latch(cache buffer lru chains):sleep20再次休眠get_latch(cache buffer lru chains):spin5獲取到閂鎖查找可用DB BUFFER3寫入數(shù)據(jù)1get_latch(cache buffer chains):spin2獲取閂鎖以便將cache鏈入30537如何發(fā)現(xiàn)現(xiàn)閂鎖等等待v$session_wait,v$latch,v$latch_children等等視圖

9、Statspack報報告/AWR報報告：最最好的工工具OEMperformancemanagerdbconsole/ADDM第三方腳腳本或工工具LATCH分析析的主要要思路理解LATCH的基本本原理和和算法發(fā)現(xiàn)LATCH FREE問問題找出存在在嚴(yán)重沖沖突的LATCH找出存在在問題的的LATCH相相關(guān)的內(nèi)內(nèi)核對象象分析為什什么該閂閂鎖請求求那么高高，為什什么等待待時間那那么長綜合系統(tǒng)統(tǒng)和應(yīng)用用情況提提出優(yōu)化化建議一種特殊殊的閂鎖鎖-MUTEX從Oracle 10.2開開始使用用Mutex來來實現(xiàn)部部分內(nèi)存存的保護(hù)護(hù)10.2.0.2開始始CURSOR操作中中替代library cache,lib

10、rarycachpinMutex用來來保護(hù)內(nèi)內(nèi)存的訪訪問,保保證內(nèi)存存訪問的的串行性性和LATCH不不同，一一個Mutex只保護(hù)護(hù)一塊內(nèi)內(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-UX PA-RISCSTATSPACK/AWR報告Statspack/AWR報告是是最好的的LATCH問問題分析析工具LatchActivityforDBLatchSleepbreakdow

11、nfor DBLatchMiss Sourcesfor DBChildLatchStatistics DB閂鎖總體體情況閂鎖休眠眠情況分分解閂鎖問題題源分析析子閂鎖情情況共享池相相關(guān)的閂閂鎖共享池相相關(guān)LATCH一般和和共享池池不足或或者分析析過于頻頻繁有關(guān)關(guān)如果共享享池命中中率不高高或者共共享池使使用率接接近于100%使用，需要加加大共享享池共享池碎碎片問題題也會加加大閂鎖鎖競爭sharedpoollibrary cachelibrary cache pinrowcacheobjectsrowcacheenqueuelatchDBCACHE相關(guān)關(guān)閂鎖和LRU CHAINS或者者HASHCHA

12、INS相相關(guān)cachebufferhandlescachebuffers chainscachebuffers lruchainmultiblock readobjectsREDO LOG相關(guān)關(guān)閂鎖REDO LOG相關(guān)關(guān)閂鎖競競爭一般般由于以以下原因因：LOGBUFFER太小過于頻繁繁的COMMITREDO LOG的IO性能能不佳LOGSWITCH過于頻頻繁歸檔出現(xiàn)現(xiàn)問題或或者歸檔檔過慢主要閂鎖鎖Redo CopyRedoallocation：9.2:LOG_PARALLELISM10G:_log_parallelism_maxRedo writingredo on-diskSCNSimula

13、torlru latch與BUGBUG2452409/BUG5918642simulatorlru latch閂鎖爭用用十分高高CPU使使用率很很高DBCACHE較大大，并且且訪問負(fù)負(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其他閂鎖鎖archive control：和歸檔檔目錄有有關(guān)process allocation：和進(jìn)程程狀態(tài)修修改有關(guān)關(guān)，在短短連接的的系統(tǒng)中中可能存存在競爭爭session allocation：和SESSI

14、ON信信息修改改有關(guān)sort extentpool：和硬硬盤排序序有關(guān)childcursorhashtable：和和SQL分析以以及CURSORVERSION有關(guān)enqueue hashchains和鎖的的管理有有關(guān)modifyparametersvalues：動態(tài)調(diào)調(diào)整參數(shù)數(shù)有關(guān)parallelqueryallocbuffer,parallelquerystats:和并并行查詢詢有關(guān)GES*：和全全局鎖有有關(guān)GCS*：和全全局CACHE有關(guān)案例分析析-現(xiàn)象象CPU使使用率突突然增加加系統(tǒng)變得得十分緩緩慢procsmemorypagefaultscpurbwavmfreereatpipofrd

15、esrinsycsussyid1763014389672355278713000008080510506161404 561763014389672335712102500000106059463213381946014010145331423436315320000001094993765137589370140101453314231984107900000125341023721593792801401014533142320065540000013046105209171229370案例分析析-TOPEVENTSTop5TimedEvents%TotalEventWaitsTime(s

16、)Ela Time-latchfree951,180467,35673.70CPUtime53,5598.45dbfile sequentialread9,592,36953,0128.36enqueue10,75129,5804.66dbfile scatteredread2,154,81918,0012.84-平均每次次閂鎖等等待時間間高達(dá)481毫毫秒案例分析析：閂鎖鎖情況PctAvgWaitPctGetGetSlpsTimeNoWait NoWaitLatchRequestsMiss/Miss(s)RequestsMiss- - -cachebufferhandles4,020,9300.10.21750cachebuffers chains1,453,078,2270.10.4#58,923,93915.9cachebuffers lruchain1,258,1110.60.245862,163,5503.0案例-子子閂鎖情情況案例分析析：分析析結(jié)論及及采取措措施故障原因因應(yīng)用對幾幾張熱表表操作頻頻繁DBCACHE出現(xiàn)現(xiàn)了熱鏈鏈解決方案案最佳方案案是修改改應(yīng)用在應(yīng)用無無法修改改的情況況下，調(diào)調(diào)整HASH鏈鏈，打散散熱鏈案例分析析：優(yōu)化化效果Top5TimedE