1.hang manager HM特性介绍
oracle 11g 新特性—hang 管理器(Hang Manager) ，HM 只在RAC 数据库中存在。
在我们诊断数据库问题的时候，经常会遇到一些数据库/进程 hang住的问题。对于hang的问题，一般来说，常见的原因有以下两种:
死锁（cycle），对于这种hang, 除非循环被打破，问题会永远存在。
某个堵塞者（blocker），进程在持有了某些资源后堵住了其他进程。当然，根据堵塞的情况，我们可以把blocker分为直接堵塞进程（immediate blocker）和根堵塞进程（root blocker）。
而root blocker 在通常情况下会处于两种状态。
1.根堵塞进程处于空闲状态，对于这种情况，终止这个进程能够解决问题。
- 根堵塞进程正在等待某些和数据库无关的资源（例如：等待I/O），对于这种情况，终止这个进程也许能解决问题。但是，从数据库的角度来讲，这已经超出了数据库的范畴。
而从数据库的角度来讲， oracle有几种死锁的发现机制。 在这篇文章中我们会介绍11g RAC的新特性 hang管理器。
hang 管理器的工作基本步骤是:
1．分配一部分内存空间用于存放hang analyze dump 信息。
2．定期搜集hang analyze dump信息（本地和全局）
- 分析搜集到的dump信息，并确认系统中是否存在hang。
- 利用分析的结果来解决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.
- 除数据库以外的其他层面的进程也和这个hang相关，例如：asm实例的进程。
- 是由于用户应用层面导致的，例如：TX锁。
- 并行查询
- 需要用户手动干预。例如：阻塞进程在等待“log file switch ”（这种等待很可能是由于归档目录对应的filesystem空间不足导致的。即使HM中知道了阻塞进程，hang的情况也无法得到解决）。
如果，hang是HM无法解决的类型，那么HM会继续跟踪这个问题。
而对于HM能够解决的问题，其解决的办法就是终止根阻塞进程。但是，如果这个阻塞进程是oracle 的主要后台进程，终止它就会导致实例crash。所以，HM在解决hang的时候，也存在解决范围。这个范围是由隐含参数”_hang_resolution_scope” 控制的，这个参数可以有三个值off(也就是说HM不会去解决hang)，process（11.2.0.4版本默认值，允许HM终止阻塞进程，如果该进程不是主要的后台进程），instance（允许HM终止阻塞进程，即使该进程是主要的后台进程。终止该进程会导致实例终止）。
hang检测的过程
1.检测阶段(DETECT)
数据库会分配一部分内存空间用于存放hanganalyze dump信息。这部分内存空间在每个节点的数据库实例上都存在。 该阶段扫描实例的所有本地会话，检测是否有可能hang的会话。 每次扫描被称作一个snap。默认保存3个snap，每个snap间隔32秒，时间间隔由隐含参数”_hang_detection_interval”决定。 一旦检测到一个或多个会话出现在3个snap中(这些会话就被认为可能是hang的会话),就会向master DIA0进程发起REQHM请求，进入HA阶段；如果没有，检测到hang的会话，HM继续保留在该阶段，除了阶段性的进入HAONLY阶段。
2.hang会话分析阶段(Hang Analysis)
检测到hang的会话后，发起REQHM请求的DIA0进程将所有检测到的会话信息发送给master DIA0进程。 全局的hang analysis被启动，创建wait for graphs(WFGs),这个过程可能会跨节点，找出本地或远程的blocker。本阶段完成后进入下一阶段，分析阶段。
负责搜集这些dump信息的后台进程是DIA0(这个进程从11g才被引入)。默认情况下每3秒钟搜集本地级别hanganalyze dump, 每10秒搜集全局级别hanganalyze dump 每个实例都会拥有自己的DIA0进程，负责完成本地的hang分析。但是，对于RAC数据库，很多hang的情况会包含多个实例的进程。所以需要一个实例上的DIA0进程作为master，来对多个实例搜集到的信息进行分析。对于11g版本，节点号最小的实例的DIA0进程会成为HM的master进程。当然，在实例级别发生了重新配置后，主（master）DIA0 进程会重新在存在的实例中重新被选举出来。
3. 根源分析阶段(ANALYZE)
将root waiter和immediate waiter会话信息和Hang Signature Cache(HSC)进行匹配。如果找到匹配的记录，则更新最新的时间和计数；如果没有匹配的，创建一个新的hang记录。完成该阶段后，HM回到检测阶段。 确认阶段是由其它单独参数控制的。
4.确认阶段(verify)
被怀疑会话所在的节点会检查这些会话是否还在hang状态，并将信息发送给master DIA0进程。如果这些会话还在，确认该会话是hang的。然后进入victim阶段。
5.处理阶段(victim)
如果隐含参数”_HANG_RESOLUTION_SCOPE”值为process，HM会终止会话，如果会话终止失败，就会终止进程；
如果隐含参数”_HANG_RESOLUTION_SCOPE”值为instance，并且victim是关键的后台进程，该实例会被kill掉。
2. HM 相关的一些参数
_hang_resolution=TRUE 或者 FALSE。这个参数用于控制HM是否解决hang。
_hang_resolution_scope=OFF,PORCESS或者 INSTANCE。这个参数用于控制HM解决问题的范围。
_hang_detection= <number>。 HM检测hang的时间间隔，默认值为30（秒）。
Oracle 数据库的hang manager HM特性介绍