Oracle10GRAC database log error LMS0: 8069 GCSshadowstraversed, 4001

During this time, we found that Oracle10g CRS was indeed a bit overbearing. In the last test, we unplugged the network cable from the PrivateIP Nic, and the operating system will restart. This time we modified the system time.

During this time, it was found that the CRS of Oracle10g was indeed a little overbearing. In the last test, the network cable on the Private IP Nic was unplugged and the operating system will restart. This time, the system time was modified.

The following error is reported in the 1alert log of an aix 10g rac database node: LMS 0: 8069 GCS shadows traversed and 4001 replayed due to node 2 restart.

Then I checked some information online. If the system time is modified, the above error will be reported and the machine will be restarted.

Reprinted an article on kamus on itpub:

Except for Windows and Linux, changing the operating system time of RAC after 10.2.0.2 will cause the operating system to restart.

In the test of Oracle 10.2.0.3 RAC, if the system time of a node modified exceeds 1.5 seconds, the node will be automatically restarted.

The processing method is so cool ......

For more information, see Internal Only's Metalink Note 308051.1.

The OPROCD executable sets a signal handler for the SIGALRM handler and sets the interval timer based on the to-millisec parameter provided. the alarm handler gets the current time and checks it against the time that the alarm handler was last entered. if the difference exceeds (to-millisec + margin-millisec), it will fail; the production version will cause a node reboot.

Try to modify the OPROCD configuration in/etc/init.css d, set DISABLE_OPROCD to TRUE, and restart the system. The oprocd process does not exist in the system process, however, after the system time is modified, the machine is restarted.

If OPROCD is started in non-fatal mode, it will only write a log instead of restarting the machine: 265769.1 also describes how to change to non fatal mode, but I didn't try it.

In fatal mode, OPROCD will reboot the node if it detects excessive wait. In Non Fatal mode, it will write an error message out to the file . Oprocd. log in one of the following directories.

The final result of the attempt is to disable the entire cssd process, so as to avoid machine restart due to system time modification.

During this time, it was found that the CRS of Oracle10g was indeed a bit overbearing. In the last test, the network cable on the Private IP Nic was unplugged and the operating system will be restarted. This time, the system will restart after the system is modified, when these machines are Windows? How big is it to restart a machine on a UNIX Server? CRS is just as casual as eating and reboot.

The following section describes the statuses in which the three processes of Oracle CRS restart the machine.

Oracle clusterware has the following three daemons which may be responsible for panicing the node. it is possible that some other external entity may have rebooted the node. in the context of this discussion, we will assume that the reboot/panic was done by an Oracle clusterware daemon.

* Oprocd-Cluster fencing module
* Cssd-Cluster sychronization module which manages node membership
* Oclsomon-Cssd monitor which will monitor for cssd hangs

OPROCD This is a daemon that only gets activated when there is no vendor clusterware present on the OS. this daemon is also not activated to run on Windows/Linux. this daemon runs a tight loop and if it is not scheduled for 1.5 seconds, will reboot the node.
CSSD This daemon pings the other members of the cluster over the private network and Voting disk. If this does not get a response for Misscount seconds and Disktimeout seconds respectively, it will reboot the node.
Oclsomon This daemon monitors the CSSD to ensure that CSSD is scheduled by the OS, if it detects any problems it will reboot the node.

You need to find a way to disable these reboot features. After reboot, you cannot solve the problem.