Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to synchronize Oracle cluster time". In daily operation, I believe many people have doubts about how to synchronize Oracle cluster time. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to synchronize Oracle cluster time". Next, please follow the editor to study!

In RAC, the time of the cluster should be kept synchronized, otherwise it may lead to many problems, such as data errors caused by time-dependent applications, disordered printing of various logs, which will affect the diagnosis of the problem, and may seriously lead to cluster downtime or failure of nodes to join the cluster when the cluster is restarted.

Before 11gR2, the cluster time is synchronized by NTP, but after 11gR2, Oracle introduces the CTSS component. If the system is not configured with NTP, CTSS synchronizes the cluster time.

NTP and CTSS can coexist, and the priority of NTP is higher than that of CTSS, that is, if there are both NTP and CTSS in the system, the time of the cluster is synchronized by NTP, and CTSS will be in Observer mode. Only when the cluster shuts down all NTP services will CTSS be in Active mode.

Here are two modes of cluster time synchronization:

1) NTP synchronization mode

The discovery ntp service is recorded in the octssd.log of node 1, and the ctss service automatically switches to wait-and-see mode.

The discovery ntp service is also recorded in the octssd.log of node 2, the ctss service is in wait-and-see mode, and the primary node of the synchronization time is node 1.

2) CTSS synchronization mode

No ntp service was found in the octssd.log record in node 1, and the ctss service is in activation mode.

No ntp service was found in the octssd.log of node 2. The ctss service is in activation mode, and the primary node of synchronization time is node 1, and it will tell you that the time of the cluster is different, but because the difference is too small, it does not need to be adjusted.

Although the cluster time is inconsistent, in this case the verification result is passed, and the cluster will automatically synchronize back within the range of slight differences.

What will happen if we encounter inconsistent cluster time in our production system? what is our troubleshooting idea? the following is a scenario that simulates inconsistent cluster time.

The following alarm information was generated in the alert logs of ASM and DB after changing the time of Node 2

Click (here) to collapse or open

Warning: VKTM detected a time drift.

Time drifts can result in an unexpected behavior such as time-outs. Please check trace

File for more details.

Oracle@com2:/opt/oracle/diag/rdbms/orcl/orcl2/trace > more orcl2_vktm_34715.trc

Trace file / opt/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_vktm_34715.trc

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0-64bit Production

With the Partitioning, Real Application Clusters, OLAP, Data Mining

And Real Application Testing options

ORACLE_HOME = / opt/oracle/products/11.2.0

System name: Linux

Node name: com2

Release: 3.10.0-693.11.1.el7.x86_64

Version: # 1 SMP Fri Oct 27 05:39:05 EDT 2017

Machine: x86_64

Instance name: orcl2

Redo thread mounted by this instance: 0

Oracle process number: 4

Unix process pid: 34715, image: oracle@com2 (VKTM)

* * 2018-06-08 20 purl 01purl 39.824

* SESSION ID: (921.1) 2018-06-08 20 purl 01purl 39.824

* CLIENT ID: () 2018-06-08 20 purl 01purl 39.824

* SERVICE NAME: () 2018-06-08 20 purl 01purl 39.824

* MODULE NAME: () 2018-06-08 20 purl 01purl 39.824

* ACTION NAME: () 2018-06-08 20 purl 01purl 39.824

Kstmmainvktm: succeeded in setting elevated priority

Highres_enabled

* * 2018-06-08 20 purl 01purl 39.824

VKTM running at (1) millisec precision with DBRM quantum (100) ms

[Start] HighResTick = 1528459299824585

Kstmrmtickcnt = 0: ksudbrmseccnt [0] = 1528459299

* * 2018-06-10 20 purl 04purl 00.000

Kstmchkdrift (kstmhighrestimecntkeeper:highres): Time jumped forward by

(172844812599) usec at (1528632240000738) whereas (1000000) is allowed

The VKTM process finds that the system time has changed, and the alert log will generate corresponding alarm messages. From the resulting trace file, we can see that the system has advanced 172844812599 microseconds, that is, 48 hours (that is, the time we simulated the change), and the allowable difference range is 1 second.

The offset time is recorded in both the octssd.log and ctss status of node 2, and the verification also fails. The verification result is that the time of node 2 needs to be synchronized. At this time, because of the large difference in cluster time, the synchronization service is often unable to do, and can only be repaired by manual synchronization.

Before there is no synchronization time, restarting Node 2 cannot be started normally. From the following command, we can see that there is a problem at the ctss step. Only by changing the correct time can the cluster start normally.

At this point, the study on "how to synchronize Oracle cluster time" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.