My Oracle Support Banner

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

Last updated on MARCH 12, 2021

Applies to:

Oracle Database - Enterprise Edition - Version and later
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Linux x86-64


On : version, Clusterware

When attempting to start GI,
the following error occurs.

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.


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 [<hostname 1>] )
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 [<hostname 1>] )

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


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

$cat /etc/sysconfig/clock



To view full details, sign in with your My Oracle Support account.

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

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.