Oracle数据库性能优化实务_闩锁及闩锁优化.ppt

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 LATCH Oracle对特定的内核内存只使用一个LATCH来保护如果某些内核内存太大 Oracle会分为一些子区域 每个子区域由一个LATCH来管理 比如 多个相同功能的LRULATCH用来保护多条LRU链多个HASHLATCH来保护多条HASH链一个LATCH可以保护多个内核内存区域 但是一个内核内存区域只有一个LATCH LATCH的模拟算法 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 闩锁使用的例子 如何发现闩锁等待 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 RISC STATSPACK AWR报告 Statspack AWR报告是最好的LATCH问题分析工具LatchActivityforDBLatchSleepbreakdownforDBLatchMissSourcesforDBChildLatchStatisticsDB 闩锁总体情况 闩锁休眠情况分解 闩锁问题源分析 子闩锁情况 共享池相关的闩锁 共享池相关LATCH一般和共享池不足或者分析过于频繁有关如果共享池命中率不高或者共享池使用率接近于100 使用 需要加大共享池共享池碎片问题也会加大闩锁竞争sharedpoollibrarycachelibrarycachepinrowcacheobjectsrowcacheenqueuelatch DBCACHE相关闩锁 和LRUCHAINS或者HASHCHAINS相关cachebufferhandlescachebufferschainscachebufferslruchainmultiblockreadobjects REDOLOG相关闩锁 REDOLOG相关闩锁竞争一般由于以下原因 LOGBUFFER太小过于频繁的COMMITREDOLOG的IO性能不佳LOGSWITCH过于频繁归档出现问题或者归档过慢主要闩锁RedoCopyRedoallocation 9 2 LOG PARALLELISM10G log parallelism maxRedowritingredoon diskSCN Simulatorlrulatch与BUG BUG2452409 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 案例分析 TOPEVENTS Top5TimedEvents 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 案例 子闩锁情况 案例分析 分析结论及采取措施 故障原因应用对几张热表操作频繁DBCACHE出现了热链解决方案最佳方案是修改应用在应用无法修改的情况下 调整HASH链 打散热链 案例分析 优化效果 Top5TimedEvents TotalEventWaitsTime