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

1、Oracle数据库性能优化实务第四讲：闩锁及闩锁优化主讲人：白鳝Oracle的的锁第2页应用级锁锁：应用用中对表表等资源源进行锁锁定，保保证业务务逻辑正正确性数据字典典锁：OracleRDBMS内内核程序序员使用用的用来来保证数数据字典典访问逻逻辑正确确性的锁锁内存控制制锁：用用来保护护Oracle内部数数据结构构的锁（LATCH,MUTEX）应用程序序的锁第3页应用程序序锁的优优化取决决于应用用软件编编写人员员使用v$lock可以以观察锁锁的情况况（TM,TX）?/rdbms/admin/catblock.sql使用dba_waiters,dba_blockers来查查找阻塞塞数据字典典的锁

2、第4页OracleRDBMS也也是一个个“程序序”，需需要通过过锁机制制来保证证程序的的逻辑比如创建建一张表表要插入入sys.tab$和和sys.obj$等等数据字字典表类似这些些操作也也会在v$lock看看到锁的名字字是特殊殊的管理共享享内存的的锁Oracle的的内存结结构也必必须进行行同步互互斥保护护Oracle通通过对访访问核心心内存结结构的代代码的执执行进行行控制来来达到间间接的保保护核心心内存的的目的每个LATCH都涉及及到特定定的内核核代码要执行某某个代码码，必须须先获得得相应的的LATCHOracle通通过上述述过程，可以保保证核心心内存访访问的高高效性和和一致性性什么是闩闩锁L

3、atch可以以保证Oracle串串行访问问核心内内存Latch必须须十分高高效Latch通过过简单的的底层的的技术实实现，尽尽可能使使用操作作系统的的底层技技术Latch的申申请不通通过队列列机制闩锁的使使用Ifget_latch(latch name,mode)-执行行某段内内核代码码release(latchname);MUTLI-LATCHOracle对对特定的的内核内内存只使使用一个个LATCH来来保护如果某些些内核内内存太大大，Oracle会分分为一些些子区域域，每个个子区域域由一个个LATCH来来管理，比如：多个相同同功能的的LRU LATCH用来保保护多条条LRU链多个HASHL

4、ATCH来来保护多多条HASH链链一个LATCH可以保保护多个个内核内内存区域域，但是是一个内内核内存存区域只只有一个个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(“latch: $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相关关的时间间开销三个方面面消耗的的时间：获取LATCH的时间间(S

6、PIN:CPU时间,SLEEP等等)持有LATCH的时间间(内核核代码:cpu时间,OS调调用,锁锁等待)LATCH释放放的时间间(内核核代码:cpu时间)注意的要要点：spin消耗CPU资资源，因因此提高高_spin_count会会加大CPU开开销spin不产生生等待事事件sleep不消消耗cpu时间间，会记记录latch free等等待调整_SPIN_COUNT调整_SPIN_COUNT是十分分危险的的动作Oracle9iR2开开始支持持按照CLASS分类类设置_spin_count找到闩锁锁：selectlatch# fromv$latchnamewherename=cachebuffe

7、rschains;altersystemset _latch_classes=98:0scope=spfile;altersystemset _latch_class_0=1800scope=spfile;闩锁使用用的例子子操作闩锁等待其他等待CPU 时间说明读取（10/2512)get_latch(cache buffer chains):spin1获得闩锁以便于查找数据搜索 buffer chain5查找所需数据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继续获取get_latch(cache buffer lru chains):sleep20再次休眠get_latch(cache buffer lru chains):spin5获取到闩锁查找可用DB BUFFER3写入数据1get_latch(cache buffer chains):spin2获取闩锁以便将cache链入30537如何发现现闩锁等等待v$session_wait,v$latch,v$latch_children等等视图

9、Statspack报报告/AWR报报告：最最好的工工具OEMperformancemanagerdbconsole/ADDM第三方脚脚本或工工具LATCH分析析的主要要思路理解LATCH的基本本原理和和算法发现LATCH FREE问问题找出存在在严重冲冲突的LATCH找出存在在问题的的LATCH相相关的内内核对象象分析为什什么该闩闩锁请求求那么高高，为什什么等待待时间那那么长综合系统统和应用用情况提提出优化化建议一种特殊殊的闩锁锁-MUTEX从Oracle 10.2开开始使用用Mutex来来实现部部分内存存的保护护10.2.0.2开始始CURSOR操作中中替代library cache,lib

10、rarycachpinMutex用来来保护内内存的访访问,保保证内存存访问的的串行性性和LATCH不不同，一一个Mutex只保护护一块内内存比LATCH开开销更小小LATCH：150-200条指令令MUTEX：35-40条指指令对于需要要保护一一组内存存的情况况，LATCH效率更更高MUTEX也支支持OWI在不支持持CAS的平台台上慎用用MUTEXLATCH设置_kks_use_mutex_pin比如HP-UX PA-RISCSTATSPACK/AWR报告Statspack/AWR报告是是最好的的LATCH问问题分析析工具LatchActivityforDBLatchSleepbreakdow

11、nfor DBLatchMiss Sourcesfor DBChildLatchStatistics DB闩锁总体体情况闩锁休眠眠情况分分解闩锁问题题源分析析子闩锁情情况共享池相相关的闩闩锁共享池相相关LATCH一般和和共享池池不足或或者分析析过于频频繁有关关如果共享享池命中中率不高高或者共共享池使使用率接接近于100%使用，需要加加大共享享池共享池碎碎片问题题也会加加大闩锁锁竞争sharedpoollibrary cachelibrary cache pinrowcacheobjectsrowcacheenqueuelatchDBCACHE相关关闩锁和LRU CHAINS或者者HASHCHA

12、INS相相关cachebufferhandlescachebuffers chainscachebuffers lruchainmultiblock readobjectsREDO LOG相关关闩锁REDO LOG相关关闩锁竞竞争一般般由于以以下原因因：LOGBUFFER太小过于频繁繁的COMMITREDO LOG的IO性能能不佳LOGSWITCH过于频频繁归档出现现问题或或者归档档过慢主要闩锁锁Redo CopyRedoallocation：9.2:LOG_PARALLELISM10G:_log_parallelism_maxRedo writingredo on-diskSCNSimula

13、torlru latch与BUGBUG2452409/BUG5918642simulatorlru latch闩锁争用用十分高高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其他闩锁锁archive control：和归档档目录有有关process allocation：和进程程状态修修改有关关，在短短连接的的系统中中可能存存在竞争争session allocation：和SESSI

14、ON信信息修改改有关sort extentpool：和硬硬盘排序序有关childcursorhashtable：和和SQL分析以以及CURSORVERSION有关enqueue hashchains和锁的的管理有有关modifyparametersvalues：动态调调整参数数有关parallelqueryallocbuffer,parallelquerystats:和并并行查询询有关GES*：和全全局锁有有关GCS*：和全全局CACHE有关案例分析析-现象象CPU使使用率突突然增加加系统变得得十分缓缓慢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-平均每次次闩锁等等待时间间高达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案例-子子闩锁情情况案例分析析：分析析结论及及采取措措施故障原因因应用对几几张热表表操作频频繁DBCACHE出现现了热链链解决方案案最佳方案案是修改改应用在应用无无法修改改的情况况下，调调整HASH链链，打散散热链案例分析析：优化化效果Top5TimedE