Oracle 10G RAC數(shù)據(jù)庫日志報錯LMS 0: 8069 GCS shadows trave

今日有套aix 10G RAC數(shù)據(jù)庫節(jié)點1alert日志報LMS 0: 8069 GCS shadows traversed, 4001 replayed如下錯誤，因節(jié)點2重啟導(dǎo)致。

后上網(wǎng)查看了些資料，如果修改系統(tǒng)時間也會報如上錯誤并導(dǎo)致機器重啟。

轉(zhuǎn)載下itpub上kamus的一篇文章：

除了Windows和Linux，10.2.0.2以后的RAC是不是修改操作系統(tǒng)時間都會導(dǎo)致操作系統(tǒng)重啟-
 

在Oracle 10.2.0.3 RAC的測試中，發(fā)現(xiàn)如果修改某個節(jié)點的系統(tǒng)時間超過1.5秒，那么這個節(jié)點會被自動重新啟動。

好狠的處理方式 ......

詳細(xì)機制參見Internal Only的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.

嘗試修改/etc/init.cssd中關(guān)于OPROCD的配置，將DISABLE_OPROCD設(shè)置為TRUE，然后重新啟動系統(tǒng)，在系統(tǒng)進程中已經(jīng)不存在oprocd進程，但是居然修改完系統(tǒng)時間以后，機器仍然被重新啟動了。

文檔中另外的描述提到，如果OPROCD是在non fatal mode狀態(tài)下啟動的，那么將只會寫一段log而不去重新啟動機器，并且在Note:265769.1中也描述了如何修改為non fatal mode，但是我沒有去嘗試。

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 <hostname>.oprocd.log in one of the following directories.

最后嘗試的結(jié)果是將整個cssd進程disable掉，這樣可以避免因為修改系統(tǒng)時間而引起機器重啟。

這段時間發(fā)現(xiàn)Oracle10g的CRS確實有些霸道，上次的測試中拔掉Private IP網(wǎng)卡上的網(wǎng)線，操作系統(tǒng)會重新啟動，這次居然修改系統(tǒng)時間也會導(dǎo)致系統(tǒng)重啟，真當(dāng)這些機器是Windows了？UNIX Server中重啟一次機器多大的事兒啊，CRS搞的跟吃飯一樣隨意，動不動reboot。

下面的這段資料描述了Oracle CRS的三個進程會在哪些狀態(tài)下重新啟動機器。

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.

需要找到方法去禁用這些reboot的特性，reboot了你又不能解決問題，瞎操什么心嘛。

服務(wù)器租用/服務(wù)器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]