在運行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