• 1. Oracle数据库性能优化实务 第10讲:诊断事件概述主讲人:白鳝华章培训网、[www.hztraining.com]华章培训网版权所有
  • 2. 警告本课程涉及的大部分技术都是无官方正式文档描述,并且无法得到官方技术支持的 部分技术可能导致数据库出现故障 在没有获得技术支持的情况下,尽量不使用本课程的技术
  • 3. 诊断事件诊断事件的主要用途: 在分析问题的时候获得更多的信息 解决系统问题: 修改Oracle的运行特性 启用某些内部功能(一般无正式文档支持)千万不要随意使用某个你不十分了解的诊断事件
  • 4. 诊断事件分类第4页根据需要DUMP数据用于分析 当某个ORA错误发生时产生DUMP 修改数据库运行特性 在数据库运行的时候获取额外的TRACE信息
  • 5. 设置诊断事件参数文件: event = " {: }*" 当前会话: alter session set events ' {: }*' 所有新会话: alter system set events ' {: }*' 设置其他会话的事件: sys.dbms_system.set_ev (sid,serial#,,,'') 使用ORADEBUG: oradebug
  • 6. 设置多个诊断事件参数文件中可以使用2种方法: 1. 设置多个EVENT参数 2. 在一个EVENT参数中设置多个EVENTevent = "10015 trace name context forever" event = "10046 trace name context forever, level 4"event = "10015 trace name context forever: 10046 trace name context forever, level 4"
  • 7. 同一个事件设置多个活动使用 (;): 使用(:) 会报错:event = "4031 trace name HEAPDUMP level 1 ; name ERRORSTACK level 3"SQL> alter session set events '4031 trace 2 name HEAPDUMP level 1 3 ; name ERRORSTACK level 3';ORA-02194: event specification syntax error 230 (minor error 210) near 'NAME'
  • 8. 使用DBMS_SYSTEMDBMS_SYSTEM 缺省只有SYS有权限使用 可以使用Grant EXECUTE 授权其他用户使用SQL> execute sys.dbms_system.set_ev - (8, 219, 10046, 12, '');sidserial#eventlevelaction
  • 9. 使用ORADEBUGORADEBUG 可以在SQL*Plus中运行 使用 ORADEBUG, 必须以 SYSDBA连接数据库 “ORADEBUG help”可以列出所有的命令 例子:SQL> oradebug dump processstate 10
  • 10. 第一类 IMMEDIATE DUMP使用 ALTER SESSION设置 参数 影响输出的TRACE的详细程度 例子: alter session set events 'immediate trace name level 'SQL> alter session set events 'immediate 2 trace name controlf level 10';
  • 11. 第二类 ON-ERROR DUMP通常在参数文件中设置 就是 ORA-xxxxx 参数会影响输出TRACE的详细程度 例如: 上述例子在ORA-60 (deadlock)发生时产生LEVEL 1的TRACEevent = " trace name errorstack level "event = "60 trace name errorstack level 1"
  • 12. 第三类 变更运行特性通常在参数文件设置 指明要变更的特性event = " trace name context forever, level "
  • 13. 第四类TRACE一般设置在参数文件中,也经常使用ALTER {SESSION|SYSTEM} 命令来设置 是要设置的事件, 用来调整输出TRACE的级别event = " trace name context forever, level "alter {session|system} set events ' trace name context forever, level ';
  • 14. 事件的作用顺序进程启动的时候会继承SYSTEM级的事件 会话级的事件通过命令设置,比如ALTER {session|system}
  • 15. 事件的搜索顺序Yes执行会话事件Yes未设置是否设置了会话级的事件?No是否设置进程级事件?No会话继承进程级事件
  • 16. 诊断事件的作用诊断事件主要用于系统故障的诊断
  • 17. 常见故障实例或者进程crash : Internal errors (ora-600) OS问题 Segmentation violations, bus errors (UNIX) Access violations (Windows) 一个进程可能由于等待某个事件而 hang 住 一个进程可能陷入非正常的循环(loop) 系统可能变慢…
  • 18. 性能故障如果没有出现HANG或者LOOP现象,那么很可能是出现了性能问题 性能优化可以从硬件、DB、应用等层面进行 建议使用STATSPACK /AWR/ADDM进行基础性能分析 EVENT 10046和TKPROF是很好的应用性能分析工具
  • 19. 分析相关TRACEalert.log 最不能忽略的文件 Trace 文件(UDUMP/BDUMP) 应用日志、SQL*PLUS TRACE等 Core dump OS日志
  • 20. 什么是HANG住HANG住分为系统级别和应用级别 某个进程等待某个资源,但是无法获得,就会出现HANG住 分析HANG的工具 各级STATE DUMP V$SESSION_WAIT, V$LOCK, V$LATCH, V$LATCHHOLDER HANGANALYZE
  • 21. 什么是LOOPING进程在等待的资源被另外一个STATE OBJECT持有 表现为等待某个事件 可以通过下面工具诊断: 各种 state dumps, 错误堆栈, bugs V$SESSION_WAIT, V$LOCK, V$LATCH, V$LATCHHOLDER
  • 22. LOOPING的分析方法做多个SYSTEMSTATE DUMP 使用ORADEBUG获得CALL STACK 通过HANGANALZYE报告 通过系统视图
  • 23. 关于STATE OBJECTState objects 包含:: processes Sessions Latches /enqueues Buffer handles 被PMON 用于故障清理 可以在SYSTEMSTATE DUMP和PROCESSSTATE DUMP中看到
  • 24. STATE OBJECTSProcessSessionCallTransactionSession
  • 25. 课间休息休息一下,下节更精彩
  • 26. STATE OBJECT HEADSO: c00000060b0067a8, type: 2, owner: 0000000000000000, flag: INIT/-/-/0x00struct kssob { ub1 kssobtyp; /* 类别 */ ub1 kssobflg; /* flags */ KSSOINIT BIT 0x01 // state object initialized KSSOFLST BIT 0x02 // state object is on free list KSSOFCLN BIT 0x04 // state object freed by PMON (for debugging) ub1 kssobdelstage; /* deletion stage */ skgsnpg kssobpg; /* numa processor group */ struct kssob * kssobown; /* owning state object */ kgglk kssoblnk; /* membership in parent's children list */ }
  • 27. PROCESS STATE
  • 28. SESSION STATE
  • 29. LIBRARY CACHE LOCK/HANDLE
  • 30. LIBRARY CACHE OBJECTS
  • 31. CALL STATE OBJECT
  • 32. ENQUEUE STATE
  • 33. TRANSACTION
  • 34. STATE OBJECT DUMPDUMP STATE OBJECT有助于故障分析 两类DUMP: Process state dumps System state dumps process state dump包含了进城的完整信息 system state dump包含了系统中所有PROCESS的DUMP
  • 35. 案例学习-如何通过SYSTEMSTATE DUMP分析问题数据库HANG住,被迫重启 需要了解为什么会HANG住 通过分析,找到diag的TRACE中包含了一个SYSTEM STATE DUMP
  • 36. 案例分析(1)分析的起点ALERT LOG中无明显线索 只有一个SYSTEM STATE DUMP可供分析 使用ass.awk分析SYSTEM STATE DUMP 找到供下一步分析的蛛丝马迹 了解当时系统的总体情况
  • 37. 案例分析(2)AWK结果 Resource Holder State Enqueue PR-00000000-00000000 41: last wait for os thread startup Latch c0000000c2df3b70 ??? Blocker Rcache object=c000000f9fdf8160, 61: waiting for log file switch (checkpoint incomplete) Enqueue US-0000004C-00000000 185: waiting for log file switch (checkpoint incomplete) Enqueue FB-00000006-0186BDC8 187: waiting for log file switch (checkpoint incomplete) LOCK: handle=c000000f388db3d0 204: waiting for log file switch (checkpoint incomplete) Object Names ~~~~~~~~~~~~ Enqueue PR-00000000-00000000 Latch c0000000c2df3b70 holding (efd=5) c0000000c2df3b70 slave cl Rcache object=c000000f9fdf8160, Enqueue US-0000004C-00000000 Enqueue FB-00000006-0186BDC8 LOCK: handle=c000000f388db3d0 TABL:REPORTXXXXXX
  • 38. 案例分析(3)解析结果BLOCKER未知 latch c0000000c2df3b70可能是分析的关键 存在一个PR锁,说明有进程正在启动 PR锁的持有者是41号进程 latch c0000000c2df3b70的持有者也是41号进程 41号进程是下一步分析的要点
  • 39. 案例分析(4)分析PROCESS STATE DUMP41号进程是MMON进程 正在等待某个子进程启动完毕 下一步分析:查看正在启动哪个进程
  • 40. 案例分析(5)OSP REQ HOLDER SO: c000000f9e6e3a20, type: 16, owner: c000000fbe3c1910, flag: INIT/-/-/0x00 (osp req holder) CHILD REQUESTS: (osp req) type=2(BACKGROUND) flags=0x20001(STATIC/-) state=8(DEAD) err=0 pg=129(default) arg1=0 arg2=(null) reply=(null) pname=m000 pid=0 parent=c000000f9e6e3a20 fulfill=0000000000000000
  • 41. 案例分析(6)本阶段结论mmon启动m000的时候,m000在启动过程中死了 这是一个很重要的疑点 下一步重点是: mmon是否持有了某个资源,hang住了本系统 大量会话等待log file switch(checkpoint incomplete),需要查看ckpt的PROCESS STATE DUMP
  • 42. 案例分析(7)CKPT SO: c000000fbb632130, type: 4, owner: c000000fbb40bc08, flag: INIT/-/-/0x00 (session) sid: 2154 trans: 0000000000000000, creator: c000000fbb40bc08, flag: (51) USR/- BSY/-/-/-/-/- DID: 0001-0025-00000004, short-term DID: 0001-0025-00000005 txn branch: 0000000000000000 oct: 0, prv: 0, sql: 0000000000000000, psql: 0000000000000000, user: 0/SYS service name: SYS$BACKGROUND waiting for enq: PR - contention blocking sess=0xc000000fbf5e4278 seq=61352 wait_time=0 seconds since wait started=62446 name|mode=50520006, 0=0, 0=0 Dumping Session Wait History for enq: PR - contention count=1 wait_time=429069 name|mode=50520006, 0=0, 0=0阻塞CKPT的会话是fbf5e4278,就是mmon
  • 43. 案例分析(8)结论mmon启动m000失败导致了mmon HANG住 mmon持有的pr锁阻塞了ckpt ckpt阻塞了log file switch 宕机4小时前故障就发生了,并出现了大量的ROW CACHE LOCK WAIT TOO LONG的告警 杀掉mmon或者调整statistics_level可解决问题,避免宕机出现
  • 44. 案例分析(9)启示首先声明读者不需要完全掌握这个分析过程,这是我们这门课程要教给大家的 了解STATE OBJECT对于分析系统至关重要 学会分析SYSTEM STATE DUMP的基本方法 从ASS.AWK开始 抓住重点对象 理清其中的关联关系
  • 45. 下节预告:优化常用诊断事件介绍优化常用的诊断事件 介绍如何使用诊断事件来进行性能分析和诊断 介绍相关工具
  • 46. 感谢您对华章培训网的支持!http://www. hztraining.com