原文链接如下：
http://www.dbaleet.org/understand_rac_cluster_health_monitor_overview_of_chm
Oracle Grid Infrastructure在11.2.0.2开始集成了一个新的功能叫CHM（Cluster Health Monitor），从名字就能猜测到CHM是一个用于Oracle集群健康状况的监控的工具。然而CHM并非是一个brand new utility，而是由一个被称为Instantaneous Problem Detection OS Tool (IPD/OS) 的工具发展演化而来，直到11.2.0.2, Oracle RAC的product management team终于决定把它集成到GI中，成为GI的一个标准QoS组件。
Oracle RAC有一类非常令人头疼的问题——节点的驱逐问题，相信每个在这个行业摸爬滚打多年的老dba或者技术支持工程师会对此深有体会。 一种非常典型的情况是： 从操作系统的日志来看，发起系统重启的命令的是Oracle的ocssd.bin进程，但是在操作系统层面却没有更多其它信息，CRS/GI中的日志也是空空如也，最多出现一些类似于节点网络心跳超时的错误。这类案例屡见不鲜，最终分析的结果往往是怀疑当时的心跳网络出现闪断，或者由于某节点操作系统负载过高出现内存不足的情况或者是Oracle的bug。但因缺乏足够的证据，建议将crs diagwait设置为13（10g）,并且安装OSW bb对操作系统的资源进行监控。如果这个问题不再出现，就往往成了一桩无头案，最终不了了之。事实上，这种结果是谁也不愿意看到的，但是dba也很无奈，因为系统或者网络与数据库往往属于不同的职能部门，在一个大型的企业需要协调其它部门的资源往往只是一厢情愿的事情，当然一般能很快能得到回复：网络监控没有发现什么异常，系统负载没有什么问题，当时的日志已经被清空，诸如此类。甚至很多客户根本就没有部署任何监控，dba要部署一个osw bb遇到的阻力却非常大。如果Oracle RAC能自带一个系统性能监控的工具，那么对于这些dba而言， CHM的出现可以算得上是福音了，或许CHM也同时意味着混沌扯皮背黑锅的时代即将结束。也许过几年回过头看，这段时间可以算得上是dark ages了。
废话少说，进入正题。从CHM的faq note（文档号1328466.1）和 Introducing Cluster Health Monitor (IPD/OS) (文档号736752.1)两篇文章我们可以窥测出关于CHM的大致情况。我这里将其信息整合起来并结合我所知道的一些所谓内幕，总结到如下几点：
1. 引入CHM的初衷是用于诊断操作系统重启，hang， 节点驱逐，性能骤降等一系列需要操作系统性能信息的问题。在Oracle支持网站的服务请求中，这些问题可以归结为一大类了，这样的惨案可谓多到数不胜数，用印地语来说就是多到比恒河的砂子还多，但是Oracle却一直没有处理这类问题的一件真正神兵利器，所以CHM的出现也就顺理成章，众望所归了。如果将OSW bb比作屠龙刀，那么CHM就是倚天剑了。
2. 在11.2.0.2开始， Linux平台和solaris平台的GI开始集成CHM；11.2.0.3开始AIX平台和Windows平台的GI开始集成CHM；如果使用更早的版本， Linux平台可以到http://www.oracle.com/technetwork/database/clustering/downloads/ipd-download-homepage-087212.html下载，Windows 32位可以到http://download.oracle.com/otndocs/products/clustering/ipd/crfpack-winnt.zip下载， 其它平台不提供单独下载。如果GI已集成CHM，请不要再单独安装，否则会造成冲突。CHM暂不支持HP Itanium平台，如果需要类似的功能只能使用OSW bb。
3. 从功能上看，CHM和OSW bb很多都是重合的，那么为什么不集成OSW bb来做同样的事情呢呢？CHM的原理是使用操作系统API来获取系统性能监控信息。注意CHM和OSW bb等监控工具并不是一样的， OSW bb是调用操作系统工具集，例如vmstat， iostat， netstat等来获取操作系统的性能信息的，而chm则是直接利用操作系统的API去做调用的，相比而言更高效。在某些极端的情况下，例如CPU负载非常高，执行操作系统的命令可能会挂起，OSW bb可能收集不到这个时间段的信息，而CHM是调用操作系统API的，所以不存在这方面的问题。CHM采样的数据理论上应该更实时，更精确。
4. 既然CHM相比OSW bb有那么多的优势，是不是意味着OSW bb应该退出历史舞台呢？我认为答案是否定的，理由就像乔老爷子所说的一样：”We’re Not Perfect.”
- CHM与OSW bb相比，收集的信息不及OSW bb全面，这主要是两者最初的定位不一样导致的： CHM的定位主要是用于专业的故障诊断， 保证GI的稳定运行；而OSW bb的则偏重于整体性能分析与诊断。
- CHM收集的信息与OSW bb相比，可读性较差。例如对于一个系统管理员而言，OSW bb的输出结果远比对应的CHM的输出要简单，更有说服力。
- CHM对于GI的版本限制较大，只支持11.2.0.2以上的GI版本，而OSW bb则没有这一类限制。
- CHM能保存操作系统性能数据的时间较短，最多只能是3天（猜测是因为保存这些信息的Berkeley DB的限制），而OSW bb则没有这方面的限制。
所以，至少目前CHM还无法完全取代OSW bb， 所以Oracle推荐同时运行CHM和OSW bb。据可靠的消息称：在Oracle Database 12c中CHM将进行大幅改进和优化并将完全取代OSW bb。例如收集的性能信息将更全面，收集的方式将更高效，可配置性将更强，信息保留的周期将更长， 输出的可读性将更好。但是OSW bb不会立刻引退，因为毕竟在某些平台没有CHM的平台和在早期的数据库版本还有用武之地。廉颇虽老，尚能饭也。
5. 在11.2.0.2以前OTN下载的CHM，其默认性能数据保留的时间是最近的24个小时；到11.2.0.2其性能数据保留的期限取决于其保留文件的大小，默认文件大小为1G，所以性能数据保留的时间最终取决于集群节点的个数， 在11.2.0.2每秒进行一次采样， 一个节点在6.9小时就会产生1G的数据。在11.2.0.3以后，这个采样时间变为没5秒一次，所以相比11.2.0.2，其性能数据保存的时间会长5倍。性能数据保存的时间短实则是CHM的软肋，饱受客户指责和诟病。通常在空间允许的情况下，我们建议将CHM性能数据的保存时间修改到最大值3天，这样不会发生周五晚上发生了一次节点驱逐，到周一早上上班CHM所有采集的所有性能数据都被覆盖这样的悲剧了。
6. CHM默认不包含图形界面的工具，如果想要使用GUI察看CHM收集的性能信息，可以到到http://www.oracle.com/technetwork/products/clustering/downloads/ipd-download-homepage-087212.html下载基于java的图形界面工具CHM/OS Graphical User Interface (CHMOSG)来进行察看。和OSW bb一样，图形界面永远只是提供给需要它的人，例如领导。
以上
Comment