溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹RAC環境一個節點出現大量GES信息怎么辦，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
對于RAC環境而言，兩個節點間出現資源搶占的情況不足為奇，不過如果類型的信息有規律的頻繁發生，就說明一定問題了。
這篇繼續解決問題。
RAC環境一個節點出現大量GES信息
刪除了鎖住資源的會話后，問題并沒有徹底解決。很快后臺重新啟動M000進程又出現了僵死的情況：
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環境有關。檢查CLUSTER系統的日志信息：
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分以后，輸出的信息已經發生了變化。這說明問題就是在這個時間點引入的。
繼續監測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環境出現了問題。
打算監測一下CLUSTER各個組件的狀態，結果發現在當前節點執行crs_stat后沒有響應，在等待時間超過了2個小時后被我中止。
而在另一個節點上運行卻沒有問題，而且顯示問題節點是正常的：
bash-3.00$ ./crs_stat -t
名稱 類型 目標 狀態 主機
------------------------------------------------------------
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
檢查節點2，發現存在多個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
而在節點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
而且，這些進程的啟動時間恰好就是問題發生的時間，十分的可疑。
清除這些進程對RAC數據庫的運行沒有影響，嘗試殺掉這些進程：
bash-3.00$ kill -9 17311 17331 17335 17359 17267 17353
切換到root殺毒root用戶啟動的racgmain進程。
root@newtrade2 # kill -9 17341
可惜殺掉了這些進程后，問題仍然沒有徹底解決。
看來唯一的辦法就是只能將問題節點的CLUSTER環境徹底重啟了。
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 例程已經關閉。
正常的SHUTDOWN IMMEDIATE已經無法關閉數據庫，只能使用ABORT方式來關閉。
下面利用root用戶執行/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
居然在關閉cluster環境的時候掛起，看來問題確實很嚴重，只有通過重啟來解決問題了。
root@newtrade2 # /etc/init.d/init.crs start
系統重啟后，手工啟動cluster環境，問題終于解決。
如果不是RAC環境，數據庫重啟勢必影響用戶的使用，而對于RAC環境，一個節點重啟并不會造成用戶無法訪問數據庫。
當然，事情總是兩個方面的，這個問題本身也是RAC環境引起的，對于單實例數據庫，不會出現類似的情況。
關于RAC環境一個節點出現大量GES信息怎么辦就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
