在上一篇文章中清除了大量的僵死进程，但是这个方法只能治标而不能治本。

除了操作系统中看到的大量racgmain check进程之外，数据库中还可以看到一些racgimon会话：

SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME
  2  FROM V$SESSION
  3  WHERE PROGRAM LIKE 'racg%';

       SID USERNAME PROGRAM                      EVENT                                TIME
---------- -------- ---------------------------- ------------------------------ ----------
       123 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138
       124 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276142
       130 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276123
       132 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145
       147 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145
       148 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276105
       150 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276111
       151 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276051
       156 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276123
       279 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276142
       284 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138
       290 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276102
       297 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138
       298 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276132
       306 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276105
       314 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client             0
       319 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145

已选择17行。

可以看到，除了其中一个之外，其他所有racgimon会话的等待时间都要比刚才清除的僵死进程时间要长，那么数据库现在共享资源被锁定的“元凶”很可能就是这些会话。但是由于对这个会话的任务不了解，而且kill这些会话的进程后果也不清楚，因此一直没有碰这些会话。经过前面的步骤，清除了大量的占用锁的会话以及处于等待的会话，问题仍然没有解决，说明刚才清除的会话都不是造成问题的根本所在。

为了避免清除掉这个racgimon进程，导致实例崩溃，在一个RAC测试环境尝试了一下杀掉racgimon会话对应的进程，发现实例并不会报错，而是随后自动启动了一个新的racgimon进程。

SQL> SELECT 'kill -9 ' || SPID
  2  FROM V$PROCESS
  3  WHERE ADDR IN
  4  (SELECT PADDR FROM V$SESSION
  5  WHERE PROGRAM LIKE 'racgimon%'
  6  AND SECONDS_IN_WAIT > 86400);

'KILL-9'||SPID
--------------------
kill -9 8042
kill -9 8219
kill -9 8221
kill -9 23136
kill -9 19091
kill -9 23140
kill -9 19441
kill -9 22653
kill -9 22655
kill -9 22686
kill -9 19406
kill -9 23171
kill -9 21666
kill -9 22004
kill -9 23134
kill -9 23169

已选择16行。

SQL> HOST
$ kill -9 8042
$ kill -9 8219
$ kill -9 8221
$ kill -9 23136
$ kill -9 19091
$ kill -9 23140
$ kill -9 19441
$ kill -9 22653
$ kill -9 22655
$ kill -9 22686
$ kill -9 19406
$ kill -9 23171
$ kill -9 21666
$ kill -9 22004
$ kill -9 23134
$ kill -9 23169
$ exit

在另一个实例上执行同样的操作：

SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME
  2  FROM V$SESSION
  3  WHERE PROGRAM LIKE 'racg%';

       SID USERNAME PROGRAM                        EVENT                                TIME
---------- -------- ------------------------------ ------------------------------ ----------
       113 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        277028
       142 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        276532
       197 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client             3
       309 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        278230
       324 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        277631
       325 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        276592

已选择6行。

SQL> SELECT 'kill -9 ' || SPID
  2  FROM V$PROCESS
  3  WHERE ADDR IN
  4  (SELECT PADDR FROM V$SESSION
  5  WHERE PROGRAM LIKE 'racgimon%'
  6  AND SECONDS_IN_WAIT > 86400);

'KILL-9'||SPID
--------------------
kill -9 10059
kill -9 10219
kill -9 4510
kill -9 9827
kill -9 10217

SQL> HOST
$ kill -9 10059
$ kill -9 10219
$ kill -9 4510
$ kill -9 9827
$ kill -9 10217
$ exit

问题仍然没有完全解决，看来只能将实例1上大量的racgmain check进程杀掉。

进程杀掉之后问题仍然没有解决，看来是数据库的状态存在问题了，现在唯一的方法就只能重启实例了，好在是RAC环境，可以先重启一个节点，然后再重启另一个。

没想到问题远比我想象的还要复杂，实例1通过svrctl命令关闭数据库没有相应，随后使用SHUTDOWN IMMEDIATE，也没有响应，最终导致所有的用户都无法登陆到实例，但是数据库并没有关闭，后台日志显示：

Wed May 27 12:25:13 2009
Starting background process EMN0
Wed May 27 12:27:13 2009
ERROR: Emon failed to start.
Shutting down instance: further logons disabled
Wed May 27 12:27:16 2009
ksvcreate: Process(m001) creation failed
Wed May 27 12:27:16 2009
Errors in file /opt/oracle/admin/tradedb/bdump/tradedb1_pmon_7173.trc:
ORA-00443: background process "EMN0" did not start
Wed May 27 12:27:19 2009
ksvcreate: Process(m001) creation failed
Wed May 27 12:28:19 2009
ksvcreate: Process(m001) creation failed
Wed May 27 12:29:19 2009
ksvcreate: Process(m001) creation failed
Wed May 27 12:30:19 2009
ksvcreate: Process(m001) creation failed

只好通过操作系统kill进程的方式，杀掉ORACLE进程，这是实例1关闭，但是实例2仍然启动，在实例2节点上执行rman错误依旧，看来必须重启整个数据库才能解决问题。

在实例2上使用SHUTDOWN ABORT：

bash-3.00$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on 星期三 5月 27 12:45:56 2009

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

连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> shutdown abort
ORACLE 例程已经关闭。

数据库的状态明显不对，显然是数据库或者是cluster状态不正常造成的，为了彻底的解决问题，只好将cluster一起重启，关闭cluster时发现关闭进程居然也hang住了：

# /etc/init.d/init.crs stop
Shutting down Oracle Cluster Ready Services (CRS):

没有别的办法，只有通过KILL进程的方法来杀掉CRS进程，由于CLUSTER进程被异常关闭，服务器自动重启：

# May 27 13:01:23 ahrac1 root: [ID 702911 user.alert] Oracle CSSD failure.  Rebooting for cluster integrity.

既然节点1已经重启，节点2上的cluster状态也是不对的，不如将节点2上的crs也重启：

# /etc/init.d/init.crs stop
Shutting down Oracle Cluster Ready Services (CRS):
May 27 12:48:03.461 | INF | daemon shutting down

同样的问题出现，关闭CLUSTER时被挂起。

只好再次采用kill进程的方法，节点2也进行了重启。

两个节点全部重启后，最不幸的事情发生了，节点1没有完成启动，随后通过ping可以看到节点1处于活动状态，但是由于网络服务没有启动，导致节点1无法正常登陆。

节点2虽然可以顺利启动，但是尝试执行/etc/init.d/init.crs start命令启动cluster时发现错误信息：

bash-3.00# /etc/init.d/init.crs start
Startup will be queued to init within 30 seconds.
bash-3.00#
bash-3.00# ps -ef|grep ora
  oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd
  oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh
    root  2713  2435   0 13:14:10 pts/1       0:00 grep ora
bash-3.00# ps -ef|grep ora
  oracle  2823  2820   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot
  oracle  2820  2727   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2727
  oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd
  oracle  2822  2821   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot
  oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh
  oracle  2821  2714   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2714
  oracle  2819  2718   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2718
  oracle  2824  2819   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot
    root  2832  2435   0 13:14:15 pts/1       0:00 grep ora
bash-3.00# ps -ef|grep ora
  oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd
  oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh
    root  2840  2435   0 13:14:17 pts/1       0:00 grep ora

检查后台进程，发现CLUSTER相关进程并没有启动，检查/tmp目录下的crsctl.2714文件，发现错误信息：

bash-3.00# more /tmp/crsctl.2714
OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [No such device or address] [6]

这个问题在以前碰到过类似的情况：http://yangtingkun.itpub.net/post/468/473939

但是这次等待了将近30分钟，节点2仍然无法访问OCR设备，看来问题越来越复杂了。