系统Hang住时用oradebug分析的方法

时间:2022-12-27 03:35:37

 系统Hang住时用oradebug分析的方法

某个用户做分析表的操作时,进程被阻塞,library cache lock,引起阻塞的进程也就是普通的查询该表的语句。

  原因是有很多这个表相关的SQL在执行,产生这方面的冲突,分析的时候要修改相关的统计数据,而统计数据对于SQL分析是有影响的,如果一个SQL在执行过程中,是不允许修改和表相关的一些信息的。

  如果系统hang住了,可以使用oradebug做一个HANGANALYZE来分析。

  HANGANALYZE是系统级的分析,属于轻量级分析,不会对系统产生影响。

  例如做一个1级的分析:

  做的方法分两部

  在SQLPLUS里,用SYS账号

  1、  oradebug setmypid

  2、  oradebug hanganalyze 1

  之后将会生成一个trace报告,例如以下内容。

  ==============

  HANG ANALYSIS:

  ==============

  Open chains found:

  Chain 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> :

  <48/29750/0x3ed60060/7856/PX Deq: Join ACK>

  -- <141/31823/0x3ed5d680/2291/library cache pin>

  Chain 2 : <sid/sess_srno/proc_ptr/ospid/wait_event> :

  <76/16377/0x3ed554b0/6507/No Wait>

  Chain 3 : <sid/sess_srno/proc_ptr/ospid/wait_event> :

  <98/8617/0x3ed65c80/4550/No Wait>

  说明:

  nodenum:定义每个session的序列号

  sid:session的sid

  sess_srno:session的Serial#

  ospid:OS的进程ID

  state:node的状态

  adjlist:表示blocker node

  predecessor:表示waiter node

  示例中,SID=141的就是被HANG主的会话,SID=48就是阻塞者。

  Sid=48的这个进程挂死了,但是他持有了library cache pin,所以阻塞了141,杀掉48(OSPID=7856)就解决问题了。

  而后根据等待事件的信息,具体原因具体分析。

  HANGANALYZE报告里的阻塞有可能是HANG住,也有可能只是由于比较慢引起的,所以在分析的时候,可以做一个HANGANALYZE,然后隔几分钟再做一次,两次对比着看,如果是比较慢引起的,两次报告的情况会发生变化,如果是HANG住了,是不会变化的