日志文件损坏，system表空间存在一致性问题，怎么办啊！！！

Question

我的oracle数据库有一个日志文件(当前日志)损坏，报错如下：
Tue Jul 19 17:56:55 2005
Errors in file /u/app/oracle/admin/ora8/bdump/ora8_pmon_707.trc:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 10818 change 7734686368671 time 07/19/05 14
:47:54
ORA-00312: online log 3 thread 1: '/dev/vx/rdsk/dg1/rora8_log_vol03'
Recovery of Online Redo Log: Thread 1 Group 3 Seq 35593 Reading mem 0
  Mem# 0 errs 0: /dev/vx/rdsk/dg1/rora8_log_vol03经过如下过程，仍不能解决，请求帮助。
1、shutdown abort
2、startup mount
3、recover database until cancel
提示：ORA-00308: cannot open archived log '/u/app/oracle/product/8.0.5/dbs/arch1_3559'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/dev/vx/rdsk/dg1/rora8_sys_vol01'4、alter database drop logfiles ....
5、alter database open resetlogs
提示：ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/dev/vx/rdsk/dg1/rora8_sys_vol01'

Answer 1

如果丢失的是联机日志文件，分两种情况处理1、丢失的是非活动的日志文件；2、丢失的是当前激活的日志文件。     如果是第一种情况，而发生故障的日志文件组又具有多个成员，可以先将数据库shutdown，然后用操作系统命令将损坏日志文件组中好的日志成员文件把损坏的成员文件覆盖（在同一个日志成员组中的所有日志文件的各为镜象的），如果其物理位置不可用可将其拷贝到新的驱动器上，使用alter database rename file ‘xxxx’ to ‘xxxx’改变文件位置，之后启动数据库，如果正常马上进行一个冷备份。如果损坏的日志组中只有一个日志成员，先mount上数据库，将其转换为noarchivelog模式，执行alter database add logfile member ‘xxx’ to group ‘x’给相关组增加一个成员，再执行alter database drop logfile member ‘bad_file’将损坏的日志文件删除，由于数据库的结构发生变动需要备份控制文件，之后将数据库改回archivelog模式，做一个冷备份。     如果丢失的是当前激活的日志文件，数据库又没有镜像而且当前日志组中所有成员均变为不可用。首先将数据库shutdown abort，从最近的一次全备份中恢复所有的数据文件，将数据库启动到mount状态。如果原来的日志文件物理位置不可用，使用alter database rename file ‘xxx’ to ‘xxx’改变文件的存放位置。然后，使用recover database until cancel命令来恢复数据库，直到提示最后一个归档日志运用完之后，输入cancel。之后用alter database open resetlogs打开数据库，如果没有问题，立即进行一个冷备份。注意！所有包含在损坏的redo log中的信息将会丢失，也就是说数据库崩溃前已经提交的数据有可能会丢失。这对于某些要求很高的应用将会损失惨重，因此应尽量使每个日志组具有多个日志成员，并且放置在不同的驱动器上一防止发生介质故障。     数据文件发生故障的情况也分为多种情况，1、丢失包含在SYSTEM表空间的数据文件；2、丢失没有回滚段的非SYSTEM数据文件；3、丢失有回滚段的非SYSTEM数据文件。     如果损坏的是系统表空间的数据文件。唯一的办法是从上一次备份中恢复受损的数据文件，（如果原位置不可用使用alter database rename命令改变新文件的位置），之后在数据库mount的状态下执行recover database/datafile对数据库进行回复，才能将数据库打开。注意：当SYSTEM表空间或其中的数据文件脱机，数据库是无法被打开的，因此必须在mount状态下将所有的恢复工作完成。     当丢失的数据文件不属于系统表空间而且也不包含回滚段时，有可选择在数据库的两种状态下进行恢复---在数据库open的状态或者在数据库mount的状态。如果用户急于访问数据库中未受损部分的数据或对损坏的数据文件进行恢复需要很长时间，可以先使受损的数据文件脱机，将数据库打开给用户访问，再恢复受损的数据文件最后将其联机。步骤如下：先在数据库mount时，将相关的数据文件或表空间进行脱机alter database datafile xxx offline，然后将数据库open，这样就能使数据库未受损的部分先供用户访问，之后再进行recover datafile/tablespace，完成后用alter database datafile/tablespace ‘xxx’ online使其恢复联机就可被访问了。 当然用户也可以选择在数据库mount状态下，用recover database/datafile将所有的恢复工作做完，将所有数据文件一起打开供用户访问。     如果丢失的数据文件是最后一种情况，即包含有回滚段的非系统表空间数据文件。也可以选择是在数据库先open的状态还是在mount状态下恢复。不过与上一种情况不同的是当包含回滚段的数据文件损坏时，如果使其先offline将数据库打开，那么所有数据库崩溃前未提交的事务涉及到的表将无法访问，也就是说在回滚段恢复前其中涉及的对象都不允许被访问。而且当所有包含回滚段的数据文件都在offline状态时，数据库无法进行任何DML操作，因此在数据库open状态恢复包含回滚段的数据文件时，可以先创建几个临时回滚段供数据使用create rollback segment temp1 tablespace system; alter rollback segment temp1 online;，当数据文件恢复后再将他们删除alter rollback segment temp1 offline; drop rollback segment temp1;。注意：当用这种方法使恢复的数据文件online之后，所有的原有回滚段将处于offline状态，必须手工使用alter rollback segment RBSxx online;使他们恢复联机状态，这样才能被数据库正常使用。如果在数据库mount状态下完成所有恢复，则不需要上述步骤。     如果丢失数据文件后，用户发现没有故障前的数据文件的备份，而且自从丢失的数据文件最早建立之后一直没有使用过resetlogs选项打开过数据库。也就是说用户的控制文件是在损坏的数据文件建立前创建的，归档日志中包括对损坏数据文件的所有重做记录。用户就还有一种恢复方法，用户可以先将损坏的数据文件或表空间脱机alter database datafile / tablespace xxx offline，之后执行alter database create datafile ‘new/xxx.dbf’ as ‘old/xxx.dbf’，数据库会根据保存在控制文件中的信息重建一个空的数据文件，之后再执行recover tablespace / datafile将所有重做记录运用到数据文件，使其完全恢复到当前状态，之后便可再将其恢复联机。     如果丢失的是最后一种文件---归档文件或归档文件所处的物理位置不可用，首先shutdown数据库，立即作一个冷备份。然后修改ini文件中的归档日志文件目的路径，重新启动数据库。以后再发生灾难只需从最新的备份中将相关文件恢复，数据库作recover时就不需要备份之前丢失的归档文件了。在Oracle 8之后的新版本中提供了log_archive_duplex_dest和log_archive_dest_1...5等参数允许保留多份归档文件到不同位置，甚至到远端服务器从而保证归档文件的可靠性