[Oracle 11g r2(11.2.0.4.0)]集群CTSS介绍

先了解oracle11g r2集群各个组件：

CTSS 是Cluster Time Synchronize Service 的缩写，顾名思义，就是负责同步集群节点时间的组件。CTSS 的功能是通过守护进程ctssd.bin 来实现的。对于10gR2 和11gR1 版本的集群，Oracle 一直推荐使用NTP 或者WTS ( Windows Time Service ）来同步集群中节点的系统时间，因为集群节点时间不同步会导致很多问题，例如：依赖于系统时间的应用产生错误的数据、诊断系统时变得很不方便、节点被重新启动、集群管理困难、系统性能变慢等。
然而，NTP 如果没有被正确地配置，也会出现一些问题，最常见的有：
①由NTP 回调系统时间导致的oprocd 进程错误的节点重启。
②系统时间调整过慢，导致节点间的时间不能及时同步。
因此，Oracle 在l11gR2 版本中推出了CTSS，为集群提供时间同步服务。

CTSS 的基本工作方式如下:
1 . 在集群中会有一个节点被选择为CTSS 的参考节点（ Reference Node ），也就是说，集群中其他节点的系统时间都要参照这个节点进行同步。
2 . 每个节点的CTSS 在运行时会查看节点中是否有第三方的时间同步服务（例如： NTP)正在运行，如果发现，CTSS 会以观察（Observe ）模式运行。反之，会以活动（Active)模式运行。在观察模式下，CTSS 并不会修改系统时间，在活动模式下，CTSS 会修改系统时间。
3 . 整个集群中，所有节点的 CTSS 必须以同一种模式运行，不能两种模式同时存在。

通过上面的描述，读者能看到 CTSS 是可以和 NTP 并存的。Oracle 的选择是，如果 NTP存在，那么就由 NTP 负责同步时间；如果 NTP 不存在，那么 CTSS就开始同步系统时间。这样做的原因是：在一个集群中不能同时有两个不同的时间同步服务一起修改系统时间，这可 能带来很糟糕的后果。同时这也从某种程度解释了为什么 Oracle 在 11gR2 这个版本中仍然建议安装 NTP。

注意：
CTSS 在验证 NTP 时， 不仅会验证 NTP 是否正在运行， 而且会验证配直文件是否存在（例如：/etc/ntpd.conf）。 因此， 如果选择使用 NTP 作为集群的时间同步服务， 请确保它被正确地配直并且运行。 否则， 如果选择 CTSS，则需确认 NTP 被停止且配直文件也被清除。
下面看一下CTSS启动日志：
more /u01/app/11.2.0/grid/log/node1/ctssd/octssd.log

Oracle Database 11g Clusterware Release 11.2.0.4.0 - Production Copyright 1996, 2011 Oracle. All rights reserved.
2017-10-12 12:55:28.182: [    CTSS][2169411328]Oracle Database CTSS Release 11.2.0.4.0 Production Copyright 2006, 2011 Oracle.  All rights reserved.
2017-10-12 12:55:28.182: [    CTSS][2169411328]ctss_scls_init: SCLs Context is 0xdd22b0
[  clsdmt][2162960128]Listening to (ADDRESS=(PROTOCOL=ipc)(KEY=node1DBG_CTSSD))
2017-10-12 12:55:28.185: [  clsdmt][2162960128]PID for the Process [22930], connkey 11 
2017-10-12 12:55:28.185: [  clsdmt][2162960128]Creating PID [22930] file for home /u01/app/11.2.0/grid host node1 bin ctss to /u01/app/11.2.0/grid/ctss/init/

ctssd.bin 发现了NTP 配置， 则CTSS 以Observe 模式启动: