Oracle数据库性能优化实务-闩锁及闩锁优化

Oracle数据库性能优化实务

第四讲：闩锁及闩锁优化主讲人：白鳝Oracle的锁第2页应用级锁：应用中对表等资源进行锁定，保证业务逻辑正确性数据字典锁：OracleRDBMS内核程序员使用的用来保证数据字典访问逻辑正确性的锁内存控制锁：用来保护Oracle内部数据结构的锁（LATCH,MUTEX）应用程序的锁第3页应用程序锁的优化取决于应用软件编写人员使用v$lock可以观察锁的情况（TM,TX）?/rdbms/admin/catblock.sql使用dba_waiters,dba_blockers来查找阻塞数据字典的锁第4页OracleRDBMS也是一个“程序”，需要通过锁机制来保证程序的逻辑比如创建一张表要插入sys.tab$和sys.obj$等数据字典表类似这些操作也会在v$lock看到锁的名字是特殊的管理共享内存的锁Oracle的内存结构也必须进行同步互斥保护Oracle通过对访问核心内存结构的代码的执行进行控制来达到间接的保护核心内存的目的每个LATCH都涉及到特定的内核代码要执行某个代码，必须先获得相应的LATCHOracle通过上述过程，可以保证核心内存访问的高效性和一致性什么是闩锁Latch可以保证Oracle串行访问核心内存Latch必须十分高效Latch通过简单的底层的技术实现，尽可能使用操作系统的底层技术Latch的申请不通过队列机制闩锁的使用Ifget_latch(‘latchname’,mode){--执行某段内核代码

release(‘latchname’);}MUTLI-LATCHOracle对特定的内核内存只使用一个LATCH来保护如果某些内核内存太大，Oracle会分为一些子区域，每个子区域由一个LATCH来管理，比如：多个相同功能的LRULATCH用来保护多条LRU链多个HASHLATCH来保护多条HASH链一个LATCH可以保护多个内核内存区域，但是一个内核内存区域只有一个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(“latch:$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相关的时间开销三个方面消耗的时间：获取LATCH的时间(SPIN:CPU时间,SLEEP等)持有LATCH的时间(内核代码:cpu时间,OS调用,锁等待)LATCH释放的时间(内核代码:cpu时间)注意的要点：spin消耗CPU资源，因此提高_spin_count会加大CPU开销spin不产生等待事件sleep不消耗cpu时间，会记录latchfree等待调整_SPIN_COUNT调整_SPIN_COUNT是十分危险的动作Oracle9iR2开始支持按照CLASS分类设置_spin_count找到闩锁：selectlatch#fromv$latchnamewherename='cachebufferschains';altersystemset"_latch_classes"="98:0"scope=spfile;altersystemset"_latch_class_0"=1800scope=spfile;闩锁使用的例子操作闩锁等待其他等待CPU时间说明读取（10/2512)get_latch('cachebufferchains'):spin1获得闩锁以便于查找数据搜索bufferchain5查找所需数据db_file_sequential_read等待5正常的IO时间get_latch('cachebufferlruchains'):spin10获取闩锁get_latch('cachebufferlruchains'):sleep10获取不到，休眠get_latch('cachebufferlruchains'):spin10继续获取get_latch('cachebufferlruchains'):sleep20再次休眠get_latch('cachebufferlruchains'):spin5获取到闩锁查找可用DBBUFFER3写入数据1get_latch('cachebufferchains'):spin2获取闩锁以便将cache链入30537如何发现闩锁等待v$session_wait,v$latch,v$latch_children等视图Statspack报告/AWR报告：最好的工具OEMperformancemanagerdbconsole/ADDM第三方脚本或工具LATCH分析的主要思路理解LATCH的基本原理和算法发现LATCHFREE问题找出存在严重冲突的LATCH找出存在问题的LATCH相关的内核对象分析为什么该闩锁请求那么高，为什么等待时间那么长综合系统和应用情况提出优化建议一种特殊的闩锁-MUTEX从Oracle10.2开始使用Mutex来实现部分内存的保护10.2.0.2开始CURSOR操作中替代librarycache,librarycachpinMutex用来保护内存的访问,保证内存访问的串行性和LATCH不同，一个Mutex只保护一块内存比LATCH开销更小LATCH：150-200条指令MUTEX：35-40条指令对于需要保护一组内存的情况，LATCH效率更高MUTEX也支持OWI在不支持CAS的平台上慎用MUTEXLATCH设置_kks_use_mutex_pin比如HP-UXPA-RISCSTATSPACK/AWR报告Statspack/AWR报告是最好的LATCH问题分析工具LatchActivityforDBLatchSleepbreakdownforDBLatchMissSourcesforDBChildLatchStatisticsDB闩锁总体情况闩锁休眠情况分解闩锁问题源分析子闩锁情况共享池相关的闩锁共享池相关LATCH一般和共享池不足或者分析过于频繁有关如果共享池命中率不高或者共享池使用率接近于100%使用，需要加大共享池共享池碎片问题也会加大闩锁竞争sharedpoollibrarycachelibrarycachepinrowcacheobjectsrowcacheenqueuelatchDBCACHE相关闩锁和LRUCHAINS或者HASHCHAINS相关cachebufferhandlescachebufferschainscachebufferslruchainmultiblockreadobjectsREDOLOG相关闩锁REDOLOG相关闩锁竞争一般由于以下原因：LOGBUFFER太小过于频繁的COMMITREDOLOG的IO性能不佳LOGSWITCH过于频繁归档出现问题或者归档过慢主要闩锁RedoCopyRedo

allocation：9.2:LOG_PARALLELISM10G:_log_parallelism_maxRedowritingredoon-diskSCNSimulatorlrulatch与BUGBUG2452409/BUG5918642simulatorlrulatch闩锁争用十分高CPU使用率很高DBCACHE较大，并且访问负载较大影响多个版本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：和归档目录有关processallocation：和进程状态修改有关，在短连接的系统中可能存在竞争sessionallocation：和SESSION信息修改有关sortextentpool：和硬盘排序有关childcursorhashtable：和SQL分析以及CURSORVERSION有关enqueuehashchains和锁的管理有关modifyparametersvalues：动态调整参数有关parallelqueryallocbuffer,parallelquerystats:和并行查询有关GES*：和全局锁有关GCS*：和全局CACHE有关案例分析-现象CPU使用率突然增加系统变得十分缓慢procsmemorypagefaultscpurbwavmfreereatpipofrdesrinsycsussyid1763014389672355278713000008080510506161404561763014389672335712102500000106059463213381946014010145331423436315320000001094993765137589370140101453314231984107900000125341023721593792801401014533142320065540000013046105209171229370

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

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

平均每次闩锁等待时间高达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案例-子闩锁情况案例分析：分析结论及采取措施故障原因应用对几张热