• 1. Oracle数据库性能优化实务 第四讲:闩锁及闩锁优化主讲人:白鳝华章培训网、[www.hztraining.com]华章培训网版权所有
  • 2. Oracle的锁第2页应用级锁:应用中对表等资源进行锁定,保证业务逻辑正确性 数据字典锁:Oracle RDBMS内核程序员使用的用来保证数据字典访问逻辑正确性的锁 内存控制锁:用来保护Oracle内部数据结构的锁(LATCH,MUTEX)
  • 3. 应用程序的锁第3页应用程序锁的优化取决于应用软件编写人员 使用v$lock可以观察锁的情况(TM,TX) ?/rdbms/admin/catblock.sql 使用dba_waiters,dba_blockers来查找阻塞
  • 4. 数据字典的锁第4页Oracle RDBMS也是一个“程序”,需要通过锁机制来保证程序的逻辑 比如创建一张表要插入sys.tab$和sys.obj$等数据字典表 类似这些操作也会在v$lock看到 锁的名字是特殊的
  • 5. 管理共享内存的锁Oracle的内存结构也必须进行同步互斥保护 Oracle通过对访问核心内存结构的代码的执行进行控制来达到间接的保护核心内存的目的 每个LATCH都涉及到特定的内核代码 要执行某个代码,必须先获得相应的LATCH Oracle通过上述过程,可以保证核心内存访问的高效性和一致性
  • 6. 什么是闩锁Latch可以保证Oracle串行访问核心内存 Latch必须十分高效 Latch通过简单的底层的技术实现,尽可能使用操作系统的底层技术 Latch的申请不通过队列机制
  • 7. 闩锁的使用If get_latch(‘latch name’, mode) { --执行某段内核代码 release(‘latch name’); }
  • 8. MUTLI-LATCHOracle对特定的内核内存只使用一个LATCH来保护 如果某些内核内存太大,Oracle会分为一些子区域,每个子区域由一个LATCH来管理,比如: 多个相同功能的LRU LATCH用来保护多条LRU链 多个HASH LATCH来保护多条HASH 链 一个LATCH可以保护多个内核内存区域,但是一个内核内存区域只有一个LATCH
  • 9. LATCH的模拟算法Function Get_Latch(latch_name,mode){ If Mode eq ‘immediate’ { If Fast_Get(latch_name) { return TRUE Else { return FALSE } } Else { If Fast_Get(latch_name){ return TRUE } Else { while ( 1 == 1 ){ if Spin_Get(latch_name){ return TRUE } Else { Register_Event(“latch: $latch”) Sleep(try++) } } } } }Function Fast_Get(latch_name) { If try_to_get_latch(latch_name){ return TRUE } Else { return FALSE } } Function Spin_Get(latch_name) { for i = 1 to _spin_count{ If Fast_Get(latch_name) { return TRUE } } } Function Sleep(try) { sleeptime = decode(try,0,0,1,10,2,20,3,~40,4,~80,...~2000) sleep(sleeptime) }
  • 10. LATCH相关的时间开销三个方面消耗的时间: 获取LATCH的时间(SPIN:CPU时间,SLEEP等) 持有LATCH的时间(内核代码:cpu时间,OS调用,锁等待) LATCH释放的时间(内核代码:cpu时间) 注意的要点: spin消耗CPU资源,因此提高_spin_count会加大CPU开销 spin不产生等待事件 sleep不消耗cpu时间,会记录latch free等待
  • 11. 调整_SPIN_COUNT调整_SPIN_COUNT是十分危险的动作 Oracle 9i R2开始支持按照CLASS分类设置_spin_count 找到闩锁:select latch# from v$latchname where name='cache buffers chains'; alter system set "_latch_classes"="98:0" scope=spfile; alter system set "_latch_class_0"=1800 scope=spfile;
  • 12. 闩锁使用的例子操作闩锁等待其他等待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('cache 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
  • 13. 如何发现闩锁等待v$session_wait,v$latch,v$latch_children等视图 Statspack报告/AWR报告:最好的工具 OEM performance manager db console/ADDM 第三方脚本或工具
  • 14. LATCH分析的主要思路理解LATCH的基本原理和算法 发现LATCH FREE问题 找出存在严重冲突的LATCH 找出存在问题的LATCH相关的内核对象 分析为什么该闩锁请求那么高,为什么等待时间那么长 综合系统和应用情况提出优化建议
  • 15. 一种特殊的闩锁-MUTEX从Oracle 10.2开始使用Mutex来实现部分内存的保护 10.2.0.2开始CURSOR操作中替代library cache,library cach pin Mutex用来保护内存的访问,保证内存访问的串行性 和LATCH不同,一个Mutex只保护一块内存 比LATCH开销更小 LATCH:150-200条指令 MUTEX:35-40条指令 对于需要保护一组内存的情况,LATCH效率更高 MUTEX也支持OWI 在不支持CAS的平台上慎用MUTEX LATCH 设置_kks_use_mutex_pin 比如HP-UX PA-RISC
  • 16. STATSPACK/AWR报告Statspack/AWR报告是最好的LATCH问题分析工具 Latch Activity for DB Latch Sleep breakdown for DB Latch Miss Sources for DB Child Latch Statistics DB
  • 17. 闩锁总体情况
  • 18. 闩锁休眠情况分解
  • 19. 闩锁问题源分析
  • 20. 子闩锁情况
  • 21. 共享池相关的闩锁共享池相关LATCH一般和共享池不足或者分析过于频繁有关 如果共享池命中率不高或者共享池使用率接近于100%使用,需要加大共享池 共享池碎片问题也会加大闩锁竞争 shared pool library cache library cache pin row cache objects row cache enqueue latch
  • 22. DB CACHE相关闩锁和LRU CHAINS或者HASH CHAINS相关 cache buffer handles cache buffers chains cache buffers lru chain multiblock read objects
  • 23. REDO LOG相关闩锁REDO LOG相关闩锁竞争一般由于以下原因: LOG BUFFER太小 过于频繁的COMMIT REDO LOG的IO性能不佳 LOG SWITCH过于频繁 归档出现问题或者归档过慢 主要闩锁 Redo Copy Redo  allocation : 9.2:LOG_PARALLELISM 10G:_log_parallelism_max Redo writing redo on-disk SCN
  • 24. Simulator lru latch与BUGBUG 2452409/BUG 5918642 simulator lru latch闩锁争用十分高 CPU使用率很高 DB CACHE较大,并且访问负载较大 影响多个版本 9.2.0.5 10.1.0.2 10.2.0.3 11.1.0.6 解决方案 9.2,10.1:STATISTICS_LEVEL = BASIC 10.2:db_cache_advice = OFF
  • 25. 其他闩锁archive control:和归档目录有关 process allocation:和进程状态修改有关,在短连接的系统中可能存在竞争 session allocation:和SESSION信息修改有关 sort extent pool:和硬盘排序有关 child cursor hash table:和SQL分析以及CURSOR VERSION有关 enqueue hash chains和锁的管理有关 modify parameters values:动态调整参数有关 parallel query alloc buffer,parallel query stats :和并行查询有关 GES*:和全局锁有关 GCS*:和全局CACHE有关
  • 26. 案例分析-现象CPU使用率突然增加 系统变得十分缓慢 procs memory page faults cpu r b w avm free re at pi po fr de sr in sy cs us sy id 176 3 0 1438967 235527 87 13 0 0 0 0 0 8080 51050 6161 40 4 56 176 3 0 1438967 233571 210 25 0 0 0 0 0 10605 94632 13381 94 6 0 140 1 0 1453314 234363 153 20 0 0 0 0 0 10949 93765 13758 93 7 0 140 1 0 1453314 231984 107 9 0 0 0 0 0 12534 102372 15937 92 8 0 140 1 0 1453314 232006 55 4 0 0 0 0 0 13046 105209 17122 93 7 0
  • 27. 案例分析-TOP EVENTSTop 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- latch free 951,180 467,356 73.70 CPU time 53,559 8.45 db file sequential read 9,592,369 53,012 8.36 enqueue 10,751 29,580 4.66 db file scattered read 2,154,819 18,001 2.84 ------------------------------------------------------------- 平均每次闩锁等待时间高达481毫秒
  • 28. 案例分析:闩锁情况 Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ cache buffer handles 4,020,930 0.1 0.2 175 0 cache buffers chains 1,453,078,227 0.1 0.4 ###### 58,923,939 15.9 cache buffers lru chain 1,258,111 0.6 0.2 458 62,163,550 3.0
  • 29. 案例-子闩锁情况
  • 30. 案例分析:分析结论及采取措施故障原因 应用对几张热表操作频繁 DB CACHE出现了热链 解决方案 最佳方案是修改应用 在应用无法修改的情况下,调整HASH链,打散热链
  • 31. 案例分析:优化效果Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- db file sequential read 20,137,988 1,071,848 74.05 buffer busy waits 2,245,704 193,339 13.36 db file scattered read 2,139,401 124,182 8.58 CPU time 44,780 3.09 io done 917,807 5,398 .37
  • 32. 下节预告:共享池分析共享池的基本原理 如何诊断共享池问题 10G 自动共享内存管理的利与弊
  • 33. 感谢您对华章培训网的支持!http://www. hztraining.com