如何在各个平台上配置NTP的微调模式

如何在各个平台上配置NTP的微调模式


对于11.2之前的版本，很多环境的重启原因（top5的情况）是由于NTP调整时间的步伐过大导致的，
所以RAC环境中，我们建议用户如果使用NTP，需要配置成微调模式；

具体重启的原因，请大家参考Allen Gao写的博客 ：如何诊断节点重启问题


这里介绍几个主流linux和unix平台上NTP微调的配置方法：


For Linux ：


1.请确确认各节点的ntp包已经安装 ,我这里是个4.2.2的版本


[oracle@nascds10 ~]$ rpm -qa | grep ntp


ntp-4.2.2p1-9.el5_4.1


2.请编辑各个节点的ntp.conf文件


[oracle@nascds10 ~]$ su - root


Password:


[root@nascds10 ~]# vi /etc/ntp.conf


#New ntp server added by Robinson


server 192.168.1.128 prefer <<<<===========这里是时钟服务器


restrict 192.168.7.0 mask 255.255.255.255 nomodify notrap #基于网段的限制（限制在网段192.168.7.0）


broadcastdelay 0.008


[root@nascds11 ~]# vi /etc/ntp.conf


#New ntp server added by Robinson


server 192.168.7.71 prefer


broadcastdelay 0.008


3、配置ntpd的参数，我们主要强调的是要配置成"微调的模式" 也就是在options中要加入 -x的选项


[root@nascds10 ~]# vi /etc/sysconfig/ntpd


#The following item added by Robinson


#Set to 'yes' to sycn hw clock after successful ntpdate


SYNC_HWCLOCK=yes


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


[root@nascds11 ~]# vi /etc/sysconfig/ntpd


The following item added by Robinson


SYNC_HWCLOCK=yes


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


4、自动启动配置


[root@nascds10 ~]# chkconfig ntpd on


[root@nascds11 ~]# chkconfig ntpd on


5、重启一下，使最新配置生效


[root@nascds10 ~]# service ntpd restart


Shutting down ntpd: [ OK ]


ntpd: Synchronizing with time server: [ OK ]


Syncing hardware clock to system time [ OK ]


Starting ntpd: [ OK ]


[root@nascds11 ~]# service ntpd restart


Shutting down ntpd: [ OK ]


ntpd: Synchronizing with time server: [ OK ]


Syncing hardware clock to system time [ OK ]


Starting ntpd: [ OK ]


6、检查ntpd进程的状态


[root@nascds10 ~]# ntpq -p


remote refid st t when poll reach delay offset jitter


==============================================================================


LOCAL(0) .LOCL. 10 l 40 64 1 0.000 0.000 0.001


[root@nascds11 ~]# ntpq -p


remote refid st t when poll reach delay offset jitter


==============================================================================


test.oracle.com .INIT. 16 u 60 64 0 0.000 0.000 0.000


LOCAL(0) .LOCL. 10 l 59 64 1 0.000 0.000 0.001




For Aix:




1. NTP的同步设置 编辑 /etc/ntp.conf文件, 内容如下:


----------------------------


#broadcastclient


server 192.168.5.2


driftfile /etc/ntp.drift


tracefile /etc/ntp.trace


slewalways yes


----------------------------


我们这里还是要强调微调slewalways ,这个值的默认设置是no，也就是说如果您不设置，NTP最大可一次调整1000秒. 根据IBM的官方说明，如果我们不指定slewthreshold 那么默认值是 0.128 seconds. 如果想特别设置，请指定slewthreshold 的值，注意单位是second




2.在NTP客户端启动xntpd守护进程


# startsrc -s xntpd



3. 查询xntpd的状态


当 system peer 不为 'insane' 时, 表明客户端已与服务器端成功地进行了同步.


# lssrc -ls xntpd


Program name: --/usr/sbin/xntpd


Version: -------3


Leap indicator: 00 (No leap second today.) Sys peer: ------192.168.5.2 ...




关于更多的关于IBM的平台上NTP的设置，可以参考IBM的官方文档解释：


http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/ntp.conf.htm



For HP UX:



NTP在HP上的配置，是比较省心的，不容易导致RAC重启的，因为HP上的NTP默认的就是微调的模式


1、首先我们还是要编辑ntp的配置文件 /etc/rc.config.d/netdaemons，把 XNTPD 设定为1表示启动


export XNTPD=1


2、编辑配置文件 /etc/ntp.conf ，配置好时间同步服务器


server 192.168.5.2 # 第一个地址是主服务器


server 192.168.5.3 # 第二个地址是备用服务器


3、启动ntp的进程


# /sbin/init.d/xntpd start


4、检查NTP的状态


# /usr/sbin/ntpq -p


这个命令您会看到同步的地址


如果出现的结果是No association ID's returned 那么表示您失败了


关于HP主机上NTP的模式，有3种如下，在HP 平台的man page中有详细的说明：


模式1：offset below 128 milliseconds

This is the normal operating regime of NTP. A properly configured NTP hierarchy (with reasonable networking) can operate for years without ever approaching the 128 millisecond upper limit. All time adjustments are small and smooth (known as slewing), and nobody even notices the slew adjustments unless they have a cesium clock or a GPS clock and expensive instrumentation to make sophisticated measurements (HP/Agilent makes the instruments).

模式2：offset above 128 milliseconds

This regime is often encountered at power-on because, those battery-backed real-time clocks they put in computers are not too great. Because NTP is quite capable of keeping the offset below one millisecond all the time it is running, many users want to get into the normal regime quickly when an offset above 128 millisecond is encountered at startup. So in this situation NTP will (fairly quickly) make a single step change, and is usually successful in getting the offset well below 128 millisecond so there will be no more of the disruptive step changes.


模式3：offset above 1000 seconds


This is so far out of the normal operating range that NTP decides something is terribly wrong and human intervention is required. The daemon shuts down.


For Solars:


我这没有测试的平台，不过在KM (How to Configure NTP or Windows Time for Oracle Clusterware (Doc ID 1056693.1))里找到了配置的办法，这里还有Windows的配置方式


检查配置:


/usr/bin/svcs ntp


STATE STIME FMRI


online 7:39:29 svc:/network/ntp:default


ps -ef|grep ntp


root 21212 1 0 Feb 02 ? 0:33 /usr/lib/inet/xntpd



配置/etc/inet/ntp.conf 启用slewalaways


grep 'slewalways|pll' /etc/inet/ntp.conf


slewalways yes


disable pll


启动:


/usr/sbin/svcadm enable ntp





如何诊断rac环境下sysdate 返回错误时间问题


最近处理了一些rac环境下访问sysdate返回错误时间的问题，而这种问题往往出现在数据库链接是通过Listener创建的情况下，而且，大部分情况下都是和时区设置相关的。在这篇文章中我们会针对如何诊断这种问题进行解释。这篇文章适用于版本11.2.0.2 及以上版本。

首先，对问题当中涉及到的知识进行介绍。
1. 从版本11.2.0.2 开始oracle 集群（GI）开始拥有了自己的时区和一些其他配置，这些配置保存在配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt中。
例如：
TZ=Asia/Shanghai
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
TNS_ADMIN=
ORACLE_BASE=
我们能看到变量TZ 用于定义集群的时区。当然，这个集群的时区是在安装GI时从操作系统获得的。既然集群有了时区，那么我们就需要保证GI的时区和操作系统的设置是一致的，并且当操作系统的时区发生改变时，GI的时区也需要改变。而修改集群时区的基本步骤是（修改<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件，重启节点）。
2. 当数据库或者listner 使用srvctl 命令或者随着GI启动被启动时，环境变量会继承GI的时区。您也可以通过下面的命令来手动设置数据库和listener资源的环境变量。
srvctl setenv database -d <dbname> -t 'TZ=<时区>'
srvctl setenv listener -l <listenername> -t 'TZ=<时区>'
3. sysdate返回的值并不依赖于数据库的时区设置，oracle 只是简单的从操作系统获取系统时间返回（例如：调用os 函数gettimeofday）。所以，修改数据库的时区对于这种问题并没有帮助。而对应的服务器进程所使用的环境变量TZ才会影响返回的系统时间。


接下来，我们简单介绍一下客户端通过listener 连接到数据库时会经过那些过程。我们会通过一个具体的例子来解释。在这个例子中，我们使用sqlplus 创建数据库链接，并对listener进程搜集truss 信息

1.客户端连接数据库
sqlplus scott/tiger@test
2.listner 进程收到了对应的链接，并产生了对应的server process.
524732: psargs: /u01/app/11.2.0/grid/bin/tnslsnr LISTENER -inherit
......
524732: kfork() = 496094
496094: kfork() (returning as child ...) = 0
......
496094: kfork() = 483742
483742: kfork() (returning as child ...) = 0
3. 为server process指定环境变量。
483742: execve(0x0FFFFFFFFFFF2660, 0x0000000110773730, 0x000000011077B670) argc: 2
483742: argv: oracle<sid name> (LOCAL=NO) <<<<<<<< 服务器进程环境变量被指定
483742: envp: _=/u01/app/11.2.0/grid/bin/oraagent.bin LANG=en_US LOGIN=root
483742: __CLSAGENT_INCARNATION=2 _ORA_AGENT_ACTION=TRUE PATH=
483742: NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 __CLSAGENT_USER_NAME=oracle
......
483742: ENV_FILE=/u01/app/11.2.0/grid/crs/install/s_crsconfig_<node name>_env.txt
......
483742: __CLSAGENT_LOGDIR_NAME=crsd PWD=/ TZ=Asia/Shanghai <<<< 时区被指定。

我们能看到环境变量TZ的值在创建服务器进程时会被绑定到server process 中。当然，如果您没有对lisetner 搜集truss 输出。您也可以通过操作系统命令获得对应进程的环境变量，例如：ps eauwww <pid from above>，您可以通过MOS note 373303.1 中的内容获得不同平台的命令。另外，以上的数据库是通过GI agent 启动的，如果数据库是手动启动的（例如：startup 命令），那么，输出会不同。当然, pmon在注册数据库服务到listener时也会将自己的环境变量注册到对应的service上。

所以，在诊断RAC 环境下sysdate 返回错误时间的问题时，我们需要检查以下信息。
1. 操作系统级别的时区设置，并确保操作系统命令date 能返回正确的时间。对于如何查看不同平台的时区设置，请参考note 1209444.1
2. 确认GI 配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件中的变量TZ和操作系统的TZ 设置一致。
3. 确认是否在database或listener资源层面设置了TZ变量。如果设置了，是否和OS，GI的设置是一致的。
4. 另外，server process的环境变量LIBPATH 或 LD_LIBRARY_PATH 也会对oracle访问操作系统函数产生影响。而且GI 的agent进程（适用于版本11.2.0.3 及以上的版本）在启动资源时（例如:database资源）会自动的将进程的以下环境变量清空
LD_LIBRARY_PATH, SHLIB_PATH (HP-UX), LD_LIBPATH_PATH_64 (Solaris), LIBPATH（AIX）
所以，如果您的database是使用srvctl 命令启动的，就需要确认上面的环境变量被设置正确。
例如：srvctl setenv database -d <db_name> -t 'LIBPATH=<gi_home/lib>'
注意：不同的Unix平台，以上命令可能会不同。
所以，我们也去要确认database 资源的LIBPATH 或 LD_LIBRARY_PATH 变量是否被设定。
例如：srvctl getenv database -d <db_name>
另外，在诊断这种问题时，需要搜集以下信息。
1. <gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件
2. 操作系统时区设置（cat /etc/sysconfig/clock） 和环境变量TZ的设置。以及pmon进程的环境变量。
3. database和 listener资源的环境变量
例如：srvctl getenv database -d <db_name>
srvctl getenv listener -l <listener name>
4. 如果以上的信息没有问题，那么就需要搜集listener 进程的truss（或strace） 输出找到有问题的环境变量设置。
5. 如果1—4 中的信息仍然无法找到问题的原因，请搜集客户端和服务器端的sqlnet trace，以便确认是否有任何的’alter session set ...’命令修改了会话的时区或者相关的变量。
客户端sqlnet trace:设置以下参数到客户端的sqlnet.ora 文件中。
trace_level_client=16
trace_directory_client=c:\tmp ==> 确保该路径存在
trace_file_client=client
trace_unique_client=on
trace_timestamp_client=on
服务器端sqlnet trace：设置以下参数到服务器端的sqlnet.ora文件中
trace_level_server=16
trace_file_server=server
trace_directory_server=/tmp ==> 确保该路径存在
trace_timestamp_server=ON





如何诊断节点重启问题


本文对如何诊断RAC环境中节点重启问题进行了介绍。适用于10gR2和11gR1.

首先我们对能够导致节点重启的CRS进程进行介绍。
1.ocssd : 它的主要功能是节点监控（Node Monitoring）和组管理(Group Management),它是CRS的核心进程之一。节点监控是指监控集群中节点的健康，监控的方法是通过网络心跳(network heartbeat)和磁盘心跳（disk heartbeat）实现的，如果集群中的节点连续丢失磁盘心跳或网络心跳，该节点就会被从集群中驱逐，也就是节点重启。组管理导致的节点重启，我们称之为node kill escalation（只有在11gR1以及以上版本适用）,我们会在后面的文章进行详细介绍。重启需要在指定的时间（reboot time,一般为3秒）内完成。

网络心跳:ocssd.bin进程每秒钟向集群中的各个节点通过私网发送网络心跳信息，以确认各个节点是否正常。如果某个节点连续丢失网络心跳达到阀值，misscount（默认为30秒，如果存在其他集群管理软件则为600秒），集群会通过表决盘进行投票，使丢失网络心跳的节点被主节点驱逐出集群，即节点重启。如果集群只包含2个节点，则会出现脑裂，结果是节点号小的节点存活下来，即使是节点号小的节点存在网络问题。

磁盘心跳：ocssd.bin进程每秒钟都会向所有表决盘（Voting File）注册本节点的状态信息，这个过程叫做磁盘心跳。如果某个节点连续丢失磁盘心跳达到阀值，disk timeou(一般为200秒)，则该节点会自动重启以保证集群的一致性。另外，CRS只要求[N/2]+1个表决盘可用即可，其中N为表决盘数量，一般为奇数。

2.oclsomon：这个进程负责监控ocssd是否挂起，如果发现ocssd.bin存在性能问题，则重启该节点。
3.oprocd：这个进程只在Linux和Unix系统，并且第三方集群管理软件未安装的情况下才会出现。如果它发现节点挂起,则重启该节点。

注意：以上的所有进程都是由脚本init.cssd产生的。

接下来是诊断节点重启问题是经常搜集的信息。
1．操作系统日志
2．<crs主目录>/log/<节点名称>/cssd/ocssd.log
3．oprocd.log(/etc/oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*)
4．<crs主目录>/log/<节点名称>/cssd/oclsomon/oclsomon.log
5. Oracle OSWatcher 报告

接下来我们讨论如何诊断节点重启问题。
1．由ocssd导致的节点重启。
如果在ocssd.log中出现以下错误，则表示节点重启是由于丢失网络心跳。接下来需要查看和网络相关的信息，如操作系统日志，OSW报表（traceroute的输出），以确定网络层面（cluster interconnect）是否存在问题，并确定最终的原因。
[ CSSD]2012-03-02 23:56:18.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 50% heartbeat fatal, eviction in 14.494 seconds
[ CSSD]2012-03-02 23:56:25.749 [3086] >WARNING: clssnmPollingThread: node <node_name> at 75% heartbeat fatal, eviction in 7.494 seconds
[ CSSD]2012-03-02 23:56:32.749 [3086] >WARNING: clssnmPollingThread: node <node_name>at 90% heartbeat fatal, eviction in 0.494 seconds
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmPollingThread: Eviction started for node <node_name>, flags 0x040d, state 3, wt4c 0
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmDiscHelper: <node_name>, node(4) connection failed, con (1128a5530), probe(0)
[CSSD]2012-03-02 23:56:33.243 [3086] >TRACE: clssnmDiscHelper: node 4 clean up, con (1128a5530), init state 5, cur state 5
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE: clssnmDoSyncUpdate: Initiating sync 196446491
[CSSD]2012-03-02 23:56:33.243 [3600] >TRACE: clssnmDoSyncUpdate: diskTimeout set to (27000)ms

注意：如果在主节点的ocssd.log中出现以上信息的时间点要晚于节点的重启时间，则说明节点重启的原因不是丢失网络心跳。

如果ocssd.log中出现以下错误，则表示节点重启是由于丢失磁盘心跳。接下来需要查看操作系统日志，OSWatcher报告（iostat的输出），以确定i/o层面是否存在问题，并确定最终的原因。
2010-08-13 18:34:37.423: [ CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:34:37.423: [ CLSF][150477728]Opened hdl:0xf4336530 for dev:/dev/sdb8:
2010-08-13 18:34:37.429: [ SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error
Additional information: 4
Additional information: 720913
Additional information: -1)
)