罗列一下有关oprocd的知识点
oprocd是oracle在rac中引入用来fencing io的
在unix系统下，如果我们没有采用oracle之外的第三方集群软件，才会存在oprocd进程
在linux系统下，只有在10.2.0.4版本后，才会具有oprocd进程
在window下，不会存在oprocd 进程，但是会存在一个oraFenceService服务，用来实现相同的功能，该服务采用的技术是基于windows的，与oprocd不同
oprocd进程可以运行在两者模式下：fatal和no fatal，在fatal模式下，如果系统hang住，或者其他原因触发oprocd则oprocd进程会自动重启服务器。在no fatal模式下，如果系统hang住，或者其他原因触发oprocd进程，则oprocd进程会在日志中记录警告信息，但是不会重启系统。
oprocd进程具有两个参数：timeout 指定oprocd进程调用的时间间隔 margin 指定允许的时间偏差，如果时间偏差超过margin，则oprocd进程会重启系统或者记录错误信息到日志。
oprocd进程的日志文件位于：/etc/oracle/oprocd 或者 /var/opt/oracle/oprocd
oprocd进程从cssd进程派生而来，并且以root用户身份允许
[root@node2 init.d]# ps -ef | grep oprocd
root 5109 11227 0 20:37 pts/0 00:00:00 grep oprocd
root 5758 4849 0 19:14 ? 00:00:00 /bin/sh /etc/init.d/init.cssd oprocd
root 6084 5758 0 19:14 ? 00:00:00 /u01/app/crs_home/bin/oprocd.bin run -t 1000 -m 10000 -hsi 5:10:50:75:90 -f
如果一个节点被hang住了很长时间，那么集群中的其他节点会把该节点剔除出去，在这种情况下，我们需要采取措施重启被hang住的节点，以便达到fencing io的目的。oprocd被设置了两个参数：timeout 和margin，进程会每间隔timeout时间被唤醒一次，如果本次被唤醒的时间与上次被唤醒的时间间隔超过timeout+margin，那么oprocd进程会认为oracle 节点被hang住，因此会自动重启节点或者将警告信息写入日志。
通常情况下，我们可以将oprocd进程重启系统的原因归为四类：
1:：操作系统的调度问题
2：操作系统的存在硬件或者驱动问题
3：系统具有大量负载，导致调度程序无法及时调入oprocd进程
4：oracle bug
Bug 5015469 – OPROCD may reboot the node whenever the system date is moved
backwards.
Fixed in 10.2.0.3+
Fixed in 10.1.0.3 + One off patch for Bug 4206159.
Fixed in 10.2.0.4+
Fixed in 10.2.0.3+
Bug 4206159 – Oprocd is prone to time regression due to current API used (AIX only)
Diagnostic Fixes (VERY NECESSARY IN MOST CASES):
Bug 5137401 – Oprocd logfile is cleared after a reboot
Bug 5037858 – Increase the warning levels if a reboot is approaching
oprocd进程的两个参数：timeout和margin，其默认值在init.cssd 文件中指定，如
[root@node2 init.d]# cat init.cssd | grep ^OPROCD_DEFAULT_
OPROCD_DEFAULT_TIMEOUT=1000
OPROCD_DEFAULT_MARGIN=500
OPROCD_DEFAULT_HISTORGRAM=
因此，默认情况下，如果两次唤醒oprocd进程的时间间隔超过1.5s，oprocd进程就会重启系统。这往往是不合适的，如果我们手工修改init.cssd文件中的默认值，需要oracle support才可以。
如果需要突破1.5s的限制，我们可以调用init.cssd来实现目的，通过调用init.cssd可以修改两个参数：reboottime 和 diagwait，如果diagwait> reboottime,那么margin=diagwait-reboottime。在设置diagwait时，需要将集群中所有节点的所有进程停掉，都在可以造成数据损坏，只需在rac中的一个节点修改即可。建议将diagwait修改为13
[root@node2 bin]# ./crsctl get css reboottime
3
[root@node2 bin]# ./crsctl get css diagwait
13
[root@node2 bin]# ./crsctl set css diagwait 13 -force
在11.2.0.1后，我们不再需要修改diagwait，因此架构已经发生了改变。
在windows下我们也可以修改diagwait，但是与在linux下不同，修改diagwait不会造成上面的变化。
下面再来看一下有关hangcheck_timer的有关信息，hangcheck_timer与oprocd可以实现相同的功能，但是两者之间没有必然的联系
Hangcheck-Timer Module
Hangcheck-Timer Module Requirements for Oracle 9i, 10g, and 11g RAC on Linux
Starting in release 9.2.0.2 and later, Oracle RAC environments required using a new I/O fencing model, named the hangcheck-timer module. This module was implemented to replace the Watchdog module, which provided similar fencing functionality. Hangcheck-timer was subsequently delivered as part of the standard kernel distribution for Linux kernel releases 2.4 and above.
Hangcheck-timer should be loaded at boot time, and monitors the Linux kernel for long operating system hangs that could affect the reliability of a RAC node. It runs in kernel mode and uses the Time Stamp Counter (TSC) to catch scheduling delays or node hangs. This is done by setting a timer, then checking when the timer fires