6）FAN 事件的格式
除了type、status和reason外，FAN事件中还包含其他的字段用于进一步描述唯一的cluster 资源：
* event payload的版本，目前是1.0
* primary或是shadow应用Service的name（node event不包含该name）
* RAC Database的name（也不包含在node事件中）
* RAC的Instance名称（不包含在service、database和node事件中）
* cluster主机名（不包含在service和database事件中）
* service的基数（只有service的status=up事件有此项）
* 事件被检测到时，server端的时间
7）server-side callouts的实施
每个被RAC高可用结构检测的database event会导致在标准CRS callout目录中每个相应callouts的执行。在UNIX环境中，此目录是$ORACLE_BASE/product/10.1.0/crs/racg/usrco 。除非CRShome目录是通过网络共享的，否则，必须在每个RAC node上部署新的callout。
这些callouts的执行顺序是不确定的。但RAC 确保一旦以异步模式辨识出event，相应的callouts将会被调用。因此，推荐将需要按照某些顺序执行的callouts进行合并。
可建立你所需的任意数量的callouts脚本，但前提是每个callout的操作代价不会引起导致高可用性事件的繁衍。如果有许多callouts用于基于收到的event执行不同的操作，将多个callout合并为一个callout可能会更高效。
写server-side的callouts设计到以下几步：
①为了callout可以辨识event，必须解析由RAC HA结构发送的event payload。
②当辨识出发送的event后，callout需要需要对其进行过滤，避免执行在所有event的notification上。
③随后需要执行相应的event处理操作，这要依赖event本身和当前业务对恢复进程的要求。
note：处于安全的考虑，确保callout目录和它包含的callouts的写权限只有安装CRS的系统用户有。
8）下面按照书上，上一个例子吧：
脚本第一部分先是对收到的event parameters进行解析。
上面这个接着根据辨识的参数，触发相应的trouble logging program。此处，假设trouble logging 程序logTicket.exe文件已经创建。
9）配置server-side的ONS
ONS的设置是通过$ORACLE_HOME/opmn/conf/ons.config文件来控制的。该文件在安装时被自动创建。主要有三个重要的参数需要被设置。
* localport，设置了ONS的端口号，用于与本地client的会话
* remoteport，ONS用于与其他ONS进程进行对话的端口
* nodes，是ONS进程需要进行对话的特定的列表。该列表应该包括所有所有RAC ONS 进程和所有中间层的ONS 进程。Node的值可以通过host name或是IP地址的方式给出，并跟在remotport参数后面。当然，也可以使用racgonsadd_config命令存储这些数据到Oracle cluster registry（OCR）中，同时在ons.config中设置参数useocr为on。通过将nodes信息放入OCR，无需编辑每个node的文件来改变配置，而只需在任意节点上执行一个命令即可。
上图中，假设ONS已经在每个cluster node上started。这是RAC正确被安装后的默认状态。然而，如果希望使用OCR，应该编辑每个节点的ons.config文件，并在重新载入之前，添加配置到OCR中，上图中已经显示了。随后需要在每个node上执行相应的onsctl reconfig命令。
10）配置client-side的ONS
必须在需要与FAN结合的client 应用程序的主机上安装ONS。多数情况下，这些主机扮演了中间层应用服务器的角色。
所以，在client side端，必须在ONS配置文件中配置RAC node。具体配置的例子见上图。
当配置了ONS后，用onsctl start 命令start ONS进程。必须确保ONS进程一直在运行。具体可以通过onsctl ping命令来查看ONS进程是否运行着。
