RAC環(huán)境一個節(jié)點出現(xiàn)大量GES信息怎么辦

這篇文章給大家介紹RAC環(huán)境一個節(jié)點出現(xiàn)大量GES信息怎么辦，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

對于RAC環(huán)境而言，兩個節(jié)點間出現(xiàn)資源搶占的情況不足為奇，不過如果類型的信息有規(guī)律的頻繁發(fā)生，就說明一定問題了。

這篇繼續(xù)解決問題。

RAC環(huán)境一個節(jié)點出現(xiàn)大量GES信息

刪除了鎖住資源的會話后，問題并沒有徹底解決。很快后臺重新啟動M000進程又出現(xiàn)了僵死的情況：

SQL> SELECT SID, TYPE, ID1, ID2, LMODE, REQUEST, CTIME, BLOCK
  2  FROM V$TRANSACTION_ENQUEUE;

       SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------- -- ---------- ---------- ---------- ---------- ---------- ----------
       245 TX    1048582     120892          6          0          3          2
       265 TX     786453     122545          6          0        332          2
       520 TX     917569     123789          6          0       2568          2

SQL> SELECT SID, SERIAL#, STATUS, MODULE, ACTION
  2  FROM V$SESSION
  3  WHERE SID IN (265, 520);

       SID    SERIAL# STATUS   MODULE                            ACTION
---------- ---------- -------- --------------------------------- ----------------------
       265      24021 ACTIVE   MMON_SLAVE                        Auto-Flush Slave Action
       520      20179 ACTIVE   MMON_SLAVE                        Auto-DBFUS Action

SQL> SELECT SID, EVENT, P1TEXT, P1, P2TEXT, P2, P3TEXT, P3, SECONDS_IN_WAIT
  2  FROM V$SESSION_WAIT
  3  WHERE SID IN (265, 520);

SID EVENT                   P1TEXT  P1 P2TEXT      P2 P3TEXT        P3 SECONDS_IN_WAIT
--- ----------------------- ------ --- ------ ------- ------ --------- ---------------
265 gc current request      file#    4 block#   31685 id#     33619976             447
520 db file sequential read file#    4 block#    2486 blocks         1            2680

顯然，問題并沒有真正解決?？磥韱栴}和CLUSTER環(huán)境有關(guān)。檢查CLUSTER系統(tǒng)的日志信息：

bash-3.00$ cd $ORACLE_HOME/../crs/log/newtrade2
bash-3.00$ cd cssd/
bash-3.00$ tail -500 ocssd.log
 [    CSSD]2009-12-19 19:19:46.880 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100b6d400) proc(100b70510) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.155 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100b51f00) proc(100b6ad60) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.237 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100b3a100) proc(100babc70) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.477 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100ba2f80) proc(100bac710) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.568 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100b3a360) proc(100b750f0) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.568 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100b6e3c0) proc(100bb37c0) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.568 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100ba9990) proc(100ba7590) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:19:47.584 [11] >TRACE:   clssgmClientConnectMsg: Connect from con(100bb0450) proc(100bb0ed0) pid() proto(10:2:1:1)
[    CSSD]2009-12-19 19:23:14.530 [15] >TRACE:   clssnmPollingThread: node newtrade1 (1) missed(2) checkin(s)
[    CSSD]2009-12-19 19:27:16.680 [15] >TRACE:   clssnmPollingThread: node newtrade2 (2) missed(2) checkin(s)
[    CSSD]2009-12-19 19:49:42.260 [15] >TRACE:   clssnmPollingThread: node newtrade1 (1) missed(2) checkin(s)
[    CSSD]2009-12-19 19:55:57.720 [15] >TRACE:   clssnmPollingThread: node newtrade2 (2) missed(2) checkin(s)
.
.
.
[    CSSD]2009-12-23 15:22:01.500 [15] >TRACE:   clssnmPollingThread: node newtrade2 (2) missed(2) checkin(s)
[    CSSD]2009-12-23 15:22:29.780 [15] >TRACE:   clssnmPollingThread: node newtrade2 (2) missed(2) checkin(s)

在上一篇文章查詢鎖信息時，持有鎖的會話的事務就是從19日開始的，而從這里的日志也可以看到，從19日19時23分以后，輸出的信息已經(jīng)發(fā)生了變化。這說明問題就是在這個時間點引入的。

繼續(xù)監(jiān)測evmd的日志：

bash-3.00$ cd ../evmd/
bash-3.00$ tail -100 evmdOUT.log
2009-12-19 19:16:27 Read failed for subscriber object 101c01b40
2009-12-19 19:16:30 Read failed for subscriber object 101c01b40
2009-12-19 19:17:00 Read failed for subscriber object 101c01b40
2009-12-19 19:17:13 Read failed for subscriber object 101c01b40
2009-12-19 19:17:33 Read failed for subscriber object 101c01b40
.
.
.
2009-12-19 19:19:43 Read failed for subscriber object 101c01b40
2009-12-19 19:19:44 Read failed for subscriber object 101c01b40
2009-12-19 19:19:45 Read failed for subscriber object 101c01b40
2009-12-19 19:19:46 Read failed for subscriber object 101c01b40
2009-12-19 19:19:46 Read failed for subscriber object 101c01b40
2009-12-19 19:28:47 Read failed for subscriber object 101c01b40

這次倒是沒有什么新的錯誤信息，但是原本一直輸入的錯誤信息，在同樣的時間點后消失了，顯然是由于CLUSTER環(huán)境出現(xiàn)了問題。

打算監(jiān)測一下CLUSTER各個組件的狀態(tài)，結(jié)果發(fā)現(xiàn)在當前節(jié)點執(zhí)行crs_stat后沒有響應，在等待時間超過了2個小時后被我中止。

而在另一個節(jié)點上運行卻沒有問題，而且顯示問題節(jié)點是正常的：

bash-3.00$ ./crs_stat -t
名稱           類型           目標      狀態(tài)      主機       
------------------------------------------------------------
ora....rade.db application    ONLINE    ONLINE    newtrade2  
ora....e1.inst application    ONLINE    ONLINE    newtrade1  
ora....e2.inst application    ONLINE    ONLINE    newtrade2  
ora....E1.lsnr application    ONLINE    OFFLINE              
ora....de1.gsd application    ONLINE    ONLINE    newtrade1  
ora....de1.ons application    ONLINE    ONLINE    newtrade1  
ora....de1.vip application    ONLINE    ONLINE    newtrade1  
ora....E2.lsnr application    ONLINE    ONLINE    newtrade2  
ora....de2.gsd application    ONLINE    ONLINE    newtrade2  
ora....de2.ons application    ONLINE    ONLINE    newtrade2  
ora....de2.vip application    ONLINE    ONLINE    newtrade2  

檢查節(jié)點2，發(fā)現(xiàn)存在多個RACGMAIN進程：

bash-3.00$ ps -ef|grep /data
    root 10854     1   0   Sep 30 ?         670:09 /data/oracle/product/10.2/crs/bin/crsd.bin reboot
  oracle 10839     1   0   Sep 30 ?           0:00 sh -c sh -c 'ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/newtrade
  oracle 14657 14326   0   Sep 30 ?           2:45 /data/oracle/product/10.2/crs/bin/evmlogger.bin -o /data/oracle/product/10.2/cr
  oracle 14417 14266   0   Sep 30 ?           0:00 sh -c /bin/sh -c 'ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/new
  oracle 14418 14417   0   Sep 30 ?           0:00 /bin/sh -c ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/newtrade2/
  oracle 14419 14418   0   Sep 30 ?        1233:07 /data/oracle/product/10.2/crs/bin/ocssd.bin
  oracle 14326 10839   0   Sep 30 ?         103:58 /data/oracle/product/10.2/crs/bin/evmd.bin
    root 14316 14265   0   Sep 30 ?          32:00 /data/oracle/product/10.2/crs/bin/oprocd run -t 1000 -m 500 -f
  oracle 15625     1   0   Oct 06 ?           0:00 /data/oracle/product/10.2/crs/opmn/bin/ons -d
  oracle 15627 15625   0   Oct 06 ?          20:23 /data/oracle/product/10.2/crs/opmn/bin/ons -d
  oracle 16028     1   0   Sep 30 ?         378:38 /data/oracle/product/10.2/database/bin/racgimon startd newtrade
    root 17341     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check
  oracle 17311     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check
  oracle 17331     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check
  oracle 17335     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check
  oracle 21094     1   0   Jul 27 ?          11:42 /data/oracle/product/10.2/database/bin/tnslsnr LISTENER -inherit
  oracle 17359     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check
  oracle  9866 24535   0 21:51:47 pts/1       0:00 grep /data
  oracle 17267     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/database/bin/racgmain check
  oracle 17353     1   0   Dec 19 ?           0:00 /data/oracle/product/10.2/crs/bin/racgmain check

而在節(jié)點1上則不存在這樣的進程：

bash-3.00$ ps -ef|grep /data
  oracle  2150     1   0   Aug 11 ?           0:00 sh -c sh -c 'ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/newtrade
  oracle  6277     1   0   Aug 12 ?           8:05 /data/oracle/product/10.2/database/bin/tnslsnr LISTENER -inherit
  oracle  4294  4293   0   Aug 11 ?           0:00 /bin/sh -c ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/newtrade1/
    root  2153     1   0   Aug 11 ?         203:08 /data/oracle/product/10.2/crs/bin/crsd.bin reboot
  oracle  4293  4150   0   Aug 11 ?           0:00 sh -c /bin/sh -c 'ulimit -c unlimited; cd /data/oracle/product/10.2/crs/log/new
  oracle  4887  4885   0   Aug 11 ?           5:16 /data/oracle/product/10.2/crs/opmn/bin/ons -d
  oracle  4175  2150   0   Aug 11 ?          29:00 /data/oracle/product/10.2/crs/bin/evmd.bin
  oracle  4529  4175   0   Aug 11 ?           0:46 /data/oracle/product/10.2/crs/bin/evmlogger.bin -o /data/oracle/product/10.2/cr
  oracle  4295  4294   0   Aug 11 ?         284:08 /data/oracle/product/10.2/crs/bin/ocssd.bin
  oracle  9739     1   0   Aug 11 ?         110:18 /data/oracle/product/10.2/database/bin/racgimon startd newtrade
  oracle  4885     1   0   Aug 11 ?           0:00 /data/oracle/product/10.2/crs/opmn/bin/ons -d
    root  4228  4149   0   Aug 11 ?           7:30 /data/oracle/product/10.2/crs/bin/oprocd run -t 1000 -m 500 -f
  oracle 23064 15394   0 21:49:20 pts/1       0:00 grep /data

而且，這些進程的啟動時間恰好就是問題發(fā)生的時間，十分的可疑。

清除這些進程對RAC數(shù)據(jù)庫的運行沒有影響，嘗試殺掉這些進程：

bash-3.00$ kill -9 17311 17331 17335 17359 17267 17353

切換到root殺毒root用戶啟動的racgmain進程。

root@newtrade2 # kill -9 17341

可惜殺掉了這些進程后，問題仍然沒有徹底解決。

看來唯一的辦法就是只能將問題節(jié)點的CLUSTER環(huán)境徹底重啟了。

bash-3.00$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on 星期三 12月 23 22:24:34 2009

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

已連接。
SQL> shutdown abort
ORACLE 例程已經(jīng)關(guān)閉。

正常的SHUTDOWN IMMEDIATE已經(jīng)無法關(guān)閉數(shù)據(jù)庫，只能使用ABORT方式來關(guān)閉。

下面利用root用戶執(zhí)行/etc/init.d/init.crs命令：

root@newtrade2 # /etc/init.d/init.crs stop
Shutting down Oracle Cluster Ready Services (CRS):
Dec 23 22:26:03.803 | INF | daemon shutting down

居然在關(guān)閉cluster環(huán)境的時候掛起，看來問題確實很嚴重，只有通過重啟來解決問題了。

root@newtrade2 # /etc/init.d/init.crs start

系統(tǒng)重啟后，手工啟動cluster環(huán)境，問題終于解決。

如果不是RAC環(huán)境，數(shù)據(jù)庫重啟勢必影響用戶的使用，而對于RAC環(huán)境，一個節(jié)點重啟并不會造成用戶無法訪問數(shù)據(jù)庫。

當然，事情總是兩個方面的，這個問題本身也是RAC環(huán)境引起的，對于單實例數(shù)據(jù)庫，不會出現(xiàn)類似的情況。

關(guān)于RAC環(huán)境一個節(jié)點出現(xiàn)大量GES信息怎么辦就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。