2009-03-26:control file损坏引发的问题

以下是3-26到3-29处理sfis问题的一些简要过程，当时做了2手准备一边在想办法把新资料导入磁盘空间已经不足的 sfisnew，一边尽力恢复，最后在几乎绝望的情况下，恢复成功，中间走了很多弯路，oracle还是博大精深啊。

最近二周,用户总是抱怨sfis系统间歇性会死机,经观察现象为不定时(45分钟-8个小时)会突然出现大量等待会话,如下:

Node1

enq: WF - contention

gcs log flush sync

Streams AQ: qmn coordinator waiting for slave to start

log file sync(highest percentage)

Node2

gc cr request

gc current request

gc buffer busy

其他一切正常.此问题先到此,后面再说.

由于此问题始终查不到原因,故让用户停止使用系统,然后做下oracle的内存分配设置(或者其他什么设置),看能否有改善.

结果…….很遗憾的事情发生了,node2在重启德时候发生了万恶的蓝屏.然后…………..db无法启动了.

重启几次,并使用srvctl start database –d wsfis命令都不行,转到命令行模式下:

Sqlplus /nolog

Conn sys/pass@wsfis as sysdba

结果返回错误 ora-00600 [3619]……..

上网查，发现是control file文件损坏的原因。

按网上所说重建控制文件。（其实如果有用rman做备份，可以从备份中恢复。。可惜没做） Sqlplus /nolog

Conn sys/pass@wsfis as sysdba

alter database backup controlfile to trace;

@gettrcname #显示跟踪文件的名字

E:/oracle/product/10.2.0/admin/wsfis/udump/wsfis1_ora_4124.trc

然后在跟踪文件的最后找到控制文件的生成语句，格式如下：

MAXLOGFILES 192

MAXLOGMEMBERS 3

MAXDATAFILES 1024

MAXINSTANCES 32

MAXLOGHISTORY 20235

LOGFILE

GROUP 1 '+DATA/wsfis/onlinelog/group_1.257.675961651' SIZE 50M,

GROUP 2 '+DATA/wsfis/onlinelog/group_2.258.675961651' SIZE 50M

-- STANDBY LOGFILE