RAC环境一个节点出现大量GES信息怎么办

这篇文章给大家介绍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信息怎么办就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。