Oracle11gR2 Rac, after node start, clock will be callback 12 hours (Doc ID 2068067.1)

Last updated on NOVEMBER 27, 2015

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.4 and later
Linux x86-64

Symptoms

On : 11.2.0.4 version, Clusterware

When attempting to start GI,
the following error occurs.

ERROR
-----------------------
Adjust two node's clock to be consistent just before GI shutdown.
After GI startup, one nodes time will be called back for 12 hours.

<<<octssd.l01

2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm2_3: Received time sync message from master.
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm: sendtime{sec[1444935763], usec[441290]}, receivetime{sec[1444935769], usec[471424]}.
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm: The RTT of sync msg [6030134] is too large for time sync to be accurate. Recommends retry. Returns [17].
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm: Received from master (mode [0xcc] nodenum [1] hostname [ah-ehrdb01] )
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctsselect_monitor_steysync_mode: Failed in clsctssslave_sync_with_master [17]. Retries [0/3].
2015-10-16 03:02:49.471: [    CTSS][1091520832]ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting clsctssslave_msg_handler
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm1_1: Waiting for last time sync process to finish. sync_state[6].
2015-10-16 03:02:49.471: [    CTSS][1113667904]ctssslave_swm1_2: Ready to initiate new time sync process.
2015-10-16 03:02:49.472: [    CTSS][1091520832]ctsscomm_recv_cb2: Receive incoming message event. Msgtype [2].
2015-10-16 03:02:49.473: [    CTSS][1113667904]ctssslave_swm2_1: Waiting for time sync message from master. sync_state[2].
2015-10-16 03:02:49.473: [    CTSS][1091520832]ctssslave_msg_handler4_1: Waiting for slave_sync_with_master to finish sync process. sync_state[3].
2015-10-16 03:02:49.473: [    CTSS][1113667904]ctssslave_swm2_3: Received time sync message from master.
2015-10-16 03:02:49.473: [    CTSS][1113667904]clsctssslave.c:679:CLSCTSS_CVAL_SET: &cval[17a199c] prev_value[0] new_value[2408] start_tm [0] curr_tm [-625916] period [1800000].<====
2015-10-15 15:02:37.163: [    CTSS][1113667904]ctssslave_swm15: The CTSS master is behind this node. The local time offset [-43212309539 usec] is being adjusted. Sync method [1]<===time point on master node is 12 hours before this node, need to tune -43212309539 usec
2015-10-15 15:02:37.163: [    CTSS][1113667904]ctssslave_swm17: LT [1444935769sec 472861usec], MT [1444892557sec 163322usec], Delta [1285usec]
2015-10-15 15:02:37.163: [    CTSS][1113667904]ctssslave_swm19: The offset is [43212309539 usec] and sync interval set to [1]
2015-10-15 15:02:37.163: [    CTSS][1113667904]ctssslave_swm: Received from master (mode [0xcc] nodenum [1] hostname [ah-ehrdb01] )




Due to this issue, OS time of one node will be updated incorrectly.

Changes

 Customer modified OS timezone, to keep it as the same value "ASIA/SHANGHAI" on both nodes.

$cat /etc/sysconfig/clock

ZONE=“Asia/Shanghai"
UTC=true
ARC=false.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms