在运行sun-cluster的数据库服务器上遇到oracle故障的解决办法
数据库服务器和主应用服务器做了双机，实现是Suncluster,，这种情况下，故障排查异常困难。
由于Oracle服务被Cluster软件监控，服务出问题时，Cluster软件会尝试将共享盘阵切到另一个节点上，
在该节点上启动Oracle服务，而由于Oracle库文件故障，导致Oracle无法启动成功，当尝试启动超时后，
Cluster又会尝试在原节点上启动Oracle服务，从而导致共享盘阵和服务来两台机器上来回切换。
由于oracle服务和相关磁盘文件始终处于运动状态，导致查看数据库日志和数据库排查故障异常困难。
因此首先要停掉cluster停掉，以便排查数据库故障。
而停SunCluster双机软件非常麻烦，必须连系统一起停掉后，再在ok状态下用boot -x重启系统才可以。
所以我决定从资源组中将oracle服务这个资源暂停监控，以便cluster不再因为oracle服务出问题进行切换。
1.查看资源组内的资源名称
scstatus -g
2. 停止oracle 资源切换
停资源:
scswitch -n -j oracle-lsnr-rs
scswitch -n -j oracle-server-rs
命令格式：scswitch {-e | -n} -j resource[,...]
现在数据库是否启动失败不会再导致双机切换。可以排查数据库故障了
2.数据库故障排查
启动数据库时，报以下错误：
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: '/oracle/oradata/dbnms/system01.dbf'
尝试恢复数据库，执行以下命令：
SQL> recover database
完成介质恢复。
SQL> alter database open;
数据库已更改。
数据库安全打开。
原因分析：通常system01.dbf文件损坏，而数据库又处于非归档模式时，数据库基本上就无法挽救了。本次由于数据库redolog分了四个组，所以system01.dbf的变更信息还保存在redo.log中没有被覆盖到。所以在recover的时候，从redo04.log中找到了transaction数据，成功的恢复。
所以要提高数据库的可靠性，数据库一定要起归档模式。实在不能起归档模式的情况下，也可增大redo.log文件的组数量，避免redo.log的信息被很快覆盖。
附alert_dbnms.log的后台日志
Tue Feb 14 13:54:03 2012
ALTER DATABASE RECOVER database
Tue Feb 14 13:54:03 2012
Media Recovery Start
parallel recovery started with 16 processes
Tue Feb 14 13:54:12 2012
Recovery of Online Redo Log: Thread 1 Group 4 Seq 325853 Reading mem 0
Mem# 0 errs 0: /oracle/oradata/dbnms/redo04.log
Tue Feb 14 13:54:45 2012
Media Recovery Complete (dbnms)
Tue Feb 14 13:54:47 2012
Completed: ALTER DATABASE RECOVER database
Tue Feb 14 13:54:59 2012
alter database open
Tue Feb 14 13:55:00 2012
Beginning crash recovery of 1 threads
parallel recovery started with 16 processes
Tue Feb 14 13:55:00 2012
Started redo scan
Tue Feb 14 13:55:02 2012
Completed redo scan
274807 redo blocks read, 0 data blocks need recovery
Tue Feb 14 13:55:02 2012
Started redo application at
Thread 1: logseq 325853, block 183394
Tue Feb 14 13:55:02 2012
Recovery of Online Redo Log: Thread 1 Group 4 Seq 325853 Reading mem 0
Mem# 0 errs 0: /oracle/oradata/dbnms/redo04.log
Tue Feb 14 13:55:04 2012
Completed redo application
Tue Feb 14 13:55:04 2012
Completed crash recovery at
Thread 1: logseq 325853, block 458201, scn 16922087765
0 data blocks read, 0 data blocks written, 274807 redo blocks read
Tue Feb 14 13:55:05 2012
Thread 1 advanced to log sequence 325854
Thread 1 opened at log sequence 325854
