Oracle 11g 新特性 – HM（Hang Manager）简介
在这篇文章中我们会对oracle 11g 新特性—hang 管理器(Hang Manager) 进行介绍。我们需要说明，HM 只在RAC 数据库中存在。
在我们诊断数据库问题的时候，经常会遇到一些数据库/进程 hang住的问题。对于hang的问题，一般来说，常见的原因有以下两种。
死锁（cycle）。对于这种hang, 除非循环被打破，问题会永远存在。
某个堵塞者（blocker） 进程在持有了某些资源后堵住了其他进程。当然，根据堵塞的情况，我们可以把blocker 分为直接堵塞进程（immediate blocker）和根堵塞进程（root blocker）。而root blocker 在通常情况下会处于两种状态。
2.1 根堵塞进程处于空闲状态，对于这种情况，终止这个进程能够解决问题。
2.2 根堵塞进程正在等待某些和数据库无关的资源（例如：等待I/O），对于这种情况，终止这个进程也许能解决问题。但是，从数据库的角度来讲，这已经超出了数据库的范畴。
而从数据库的角度来讲， oracle有几种死锁的发现机制。 在这篇文章中我们会介绍11g RAC的新特性 hang管理器。hang 管理器的基本步骤是。
1．分配一部分内存空间用于存放hang analyze dump 信息。
2．定期搜集hang analyze dump信息（本地和全局）
3. 分析搜集到的dump信息，并确认系统中是否存在hang。
4. 利用分析的结果来解决hang问题。
接下来，我们对每个步骤进行具体的介绍。
步骤1: ORACLE 会分配一部分内存空间，我们称之为 hang analysis cache，用来存放搜集的hang analyze dump i信息。这部分内存空间在每个节点的数据库实例上都存在。
步骤2：oracle 会定期搜集hang analyze 信息，由于，HM特性是针对RAC数据库的特性，hang analyze的级别会包括本地和全局。另外，负责搜集这些dump 信息的后台进程是DIA0(这个进程从11g才被介绍)。默认情况下每3秒钟搜集本地级别hang analyze dump, 每10 秒搜集全局级别hang analyze dump。
步骤3：因为，每个节点都会搜集hang analyze dump 信息，那么，意味着每个实例都会拥有自己的DIA0进程，负责完成本地的hang 分析。但是，对于RAC数据库，很多hang的情况会包含多个实例的进程。所以，我们需要一个实例上的DIA0 进程作为master，来对多个实例搜集到的信息进行分析。对于11g版本，节点号最小的实例的DIA0进程会成为HM的master进程。当然，在实例级别发生了重新配置后，主（master）DIA0 进程会重新在存在的实例中重新被选举出来。
对于hang的问题，HM采用以下的机制来进行检测，当HM分析过几个hang analyze dump（每30秒进行一次分析，至少经过三次分析）后，就会发现有一些进程之间存在着等待关系（我们可以称之为open chain），而且在这段时间之内没有任何的改变（例如，一直等待相同的等待事件），那么，我们就可以怀疑，这些进程之间出现了hang的情况。而在进一步的验证之后，的确发现这些进程之间存在着等待关系，那么就会找到这个等待链（open chain）的根阻塞进程，并尝试通过终止阻塞进程的方式来解决这个hang.当然，对于死锁（dead lock）这种情况，我们采用的方式是，终止等待环中的一个进程。下面的图形说明了以上的基本逻辑。
![]()
步骤4: 在确认hang的确发生之后，根据hang的类型选择对应的解决方案。对于HM 来说，如果这个hang线管的进程满足以下条件之一，那么HM就无法解决这个hang.
1. 除数据库以外的其他层面的进程也和这个hang相关，例如：asm实例的进程。
2. 是由于用户应用层面导致的，例如：TX锁。
3. 并行查询
4. 需要用户手动干预。例如：阻塞进程在等待“log file switch ”（这种等待很可能是由于归档目录对应的filesystem空间不足导致的。即使HM中知道了阻塞进程，hang的情况也无法得到解决）。
如果，hang是HM无法解决的类型，那么HM会继续跟踪这个问题。 而对于HM能够解决的问题，其解决的办法就是终止根阻塞进程。但是，如果这个阻塞进程是oracle 的主要后台进程，终止它就会导致实例crash。所以，HM在解决hang的时候，也存在解决范围。这个范围是由隐含参数"_hang_resolution_scope" 控制的，这个参数可以有三个值off(默认值，也就是说HM不会去解决hang)，process（允许HM终止阻塞进程，如果该进程不是主要的后台进程），instance（允许HM终止阻塞进程，即使该进程是主要的后台进程。终止该进程会导致实例终止）。
最后，我们对和HM 相关的一些参数和trace 文件进行简单的介绍。
参数：
_hang_resolution=TRUE 或者 FALSE。这个参数用于控制HM是否解决hang。
_hang_resolution_scope=OFF,PORCESS或者 INSTANCE。这个参数用于控制HM解决问题的范围。
_hang_detection= <number>。 HM检测hang的时间间隔，默认值为30（秒）。
在我们诊断数据库问题的时候，经常会遇到一些数据库/进程 hang住的问题。对于hang的问题，一般来说，常见的原因有以下两种。
死锁（cycle）。对于这种hang, 除非循环被打破，问题会永远存在。
某个堵塞者（blocker） 进程在持有了某些资源后堵住了其他进程。当然，根据堵塞的情况，我们可以把blocker 分为直接堵塞进程（immediate blocker）和根堵塞进程（root blocker）。而root blocker 在通常情况下会处于两种状态。
2.1 根堵塞进程处于空闲状态，对于这种情况，终止这个进程能够解决问题。
2.2 根堵塞进程正在等待某些和数据库无关的资源（例如：等待I/O），对于这种情况，终止这个进程也许能解决问题。但是，从数据库的角度来讲，这已经超出了数据库的范畴。
而从数据库的角度来讲， oracle有几种死锁的发现机制。 在这篇文章中我们会介绍11g RAC的新特性 hang管理器。hang 管理器的基本步骤是。
1．分配一部分内存空间用于存放hang analyze dump 信息。
2．定期搜集hang analyze dump信息（本地和全局）
3. 分析搜集到的dump信息，并确认系统中是否存在hang。
4. 利用分析的结果来解决hang问题。
接下来，我们对每个步骤进行具体的介绍。
步骤1: ORACLE 会分配一部分内存空间，我们称之为 hang analysis cache，用来存放搜集的hang analyze dump i信息。这部分内存空间在每个节点的数据库实例上都存在。
步骤2：oracle 会定期搜集hang analyze 信息，由于，HM特性是针对RAC数据库的特性，hang analyze的级别会包括本地和全局。另外，负责搜集这些dump 信息的后台进程是DIA0(这个进程从11g才被介绍)。默认情况下每3秒钟搜集本地级别hang analyze dump, 每10 秒搜集全局级别hang analyze dump。
步骤3：因为，每个节点都会搜集hang analyze dump 信息，那么，意味着每个实例都会拥有自己的DIA0进程，负责完成本地的hang 分析。但是，对于RAC数据库，很多hang的情况会包含多个实例的进程。所以，我们需要一个实例上的DIA0 进程作为master，来对多个实例搜集到的信息进行分析。对于11g版本，节点号最小的实例的DIA0进程会成为HM的master进程。当然，在实例级别发生了重新配置后，主（master）DIA0 进程会重新在存在的实例中重新被选举出来。
对于hang的问题，HM采用以下的机制来进行检测，当HM分析过几个hang analyze dump（每30秒进行一次分析，至少经过三次分析）后，就会发现有一些进程之间存在着等待关系（我们可以称之为open chain），而且在这段时间之内没有任何的改变（例如，一直等待相同的等待事件），那么，我们就可以怀疑，这些进程之间出现了hang的情况。而在进一步的验证之后，的确发现这些进程之间存在着等待关系，那么就会找到这个等待链（open chain）的根阻塞进程，并尝试通过终止阻塞进程的方式来解决这个hang.当然，对于死锁（dead lock）这种情况，我们采用的方式是，终止等待环中的一个进程。下面的图形说明了以上的基本逻辑。
步骤4: 在确认hang的确发生之后，根据hang的类型选择对应的解决方案。对于HM 来说，如果这个hang线管的进程满足以下条件之一，那么HM就无法解决这个hang.
1. 除数据库以外的其他层面的进程也和这个hang相关，例如：asm实例的进程。
2. 是由于用户应用层面导致的，例如：TX锁。
3. 并行查询
4. 需要用户手动干预。例如：阻塞进程在等待“log file switch ”（这种等待很可能是由于归档目录对应的filesystem空间不足导致的。即使HM中知道了阻塞进程，hang的情况也无法得到解决）。
如果，hang是HM无法解决的类型，那么HM会继续跟踪这个问题。 而对于HM能够解决的问题，其解决的办法就是终止根阻塞进程。但是，如果这个阻塞进程是oracle 的主要后台进程，终止它就会导致实例crash。所以，HM在解决hang的时候，也存在解决范围。这个范围是由隐含参数"_hang_resolution_scope" 控制的，这个参数可以有三个值off(默认值，也就是说HM不会去解决hang)，process（允许HM终止阻塞进程，如果该进程不是主要的后台进程），instance（允许HM终止阻塞进程，即使该进程是主要的后台进程。终止该进程会导致实例终止）。
最后，我们对和HM 相关的一些参数和trace 文件进行简单的介绍。
参数：
_hang_resolution=TRUE 或者 FALSE。这个参数用于控制HM是否解决hang。
_hang_resolution_scope=OFF,PORCESS或者 INSTANCE。这个参数用于控制HM解决问题的范围。
_hang_detection= <number>。 HM检测hang的时间间隔，默认值为30（秒）。
此内容已被标记为最终。
显示 2 条回复
-
1.Re: Oracle 11g 新特性 – HM（Hang Manager）简介
有几个小问题:
1. Hang Manager能关掉吗?
2. Hang Manager怎么通知我它解决了哪些hang?
Thank you, Feng Gao
-
2.Re: Oracle 11g 新特性 – HM（Hang Manager）简介
Q1. Hang Manager能关掉吗?A1: 你可以通过设置_hang_resolution=false 使HM不去解决被发现的/hang, 但是不能关闭这个功能。
Q2. Hang Manager怎么通知我它解决了哪些hang?
A2：在alert.log 中HM如果解决了hang的话，会出现ora-32701 信息。
例如：
Fri Jul 09 15:10:16 2010 Errors in file /ade/b/3826074361/oracle/log/diag/rdbms/hm1/hm1/trace/hm1_dia0_2286.trc (incident=19281): ORA-32701: Possible hangs up to hang ID=1 detected <<<<<<<<<<<,id 为 1的hang被发现。 Incident details in: /ade/b/3826074361/oracle/log/diag/rdbms/hm1/hm1/incident/incdir_19281/hm1_dia0_2286_i19281.trc
......
Fri Jul 09 15:10:16 2010 DIA0 requesting termination of session sid:30 with serial # 5 (ospid:2434) on instance 1 (local instance) <<<<< HM尝试通过重视会话(ospid:2434) 的方式来解决这个hang。 due to a LOCAL, HIGH confidence hang with ID=1. Hang Resolution Reason: Automatic hang resolution was performed to free a significant number of affected sessions. ...... DIA0 terminating blocker (ospid: 2434 sid: 30 ser#: 5) of hang with ID = 1 requested by master DIA0 process on instance 1 Hang Resolution Reason: Automatic hang resolution was performed to free a significant number of affected sessions. by terminating session sid: 30 ospid: 2434 DIA0 successfully terminated session sid:30 ospid:2434 with status 31. DIA0 successfully resolved a LOCAL, HIGH confidence hang with ID=1. <<<<<<<<<<<<<<HM成功的终止了会话，hang被解决。 thanks Allen.
##详细可查看MOS
Oracle Hang Manager (Doc ID 1534591.1)
扫一扫
313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
已保存评级！