数据恢复后open提示 ora-00600 [3708][910]错误
大概是这样的过程：还是上次说的那个数据库，因为物理硬盘损坏，造成读不可靠。该损坏数据涉及到的表空间为users表空间，我在脱机情况下在操作系统中试图备份了部分的数据文件，其中有几个文件无法备份出来。我现在进行冷恢复的就是这个文件
但是备份之后又有1-2次的试图启动数据库的操作（当然也是失败的，而且在这个过程中造成了新的数据库文件错误）。
今天用这个备份后的数据来尝试恢复数据库。恢复的过程是：
1、换了新硬盘，仿照原来的结构建立目录，并把上次备份的文件拷贝到相应目录中。
2、数据库先进行正常模式下的startup，结果报告users01.dbf的00283、01157、01110错误（备注：该文件本身在os下拷贝没有问题，有问题的是users36.dbf。）。但是我查alert文件则只提示了users36.dbf错误。
3、对数据库进行recover database，此时果然只报告users36.dbf错误。
4、offline drop掉users36.dbf后启动还是报告users01.dbf错误，于是再次recover database，此时提示：“完成介质的恢复”。
5、对数据库进行open报告03113错误，于是重新连接，重新open操作，经过了漫长的等待之后，系统出现00600错误，后面代码是。我在网上查了一下该错误，所得的信息很少。
现在不知道下一步该怎么办，怕误操作造成更大的问题。我当时只考虑到对损坏的表空间进行备份，忘记了同步备份控制和日志文件以及系统表空间的文件。
请问大侠们，是不是因为控制文件和日志文件的不匹配造成这种错误？如果我忽略所有的日志文件的更改可不可以呢？谢谢各位大侠了！
在最后open时候形成的udump目录文件如附件，太深奥，根本看不懂。
alert中的内容是：
Wed Oct 29 09:47:47 2008
alter database open
Beginning crash recovery of 1 threads
Wed Oct 29 09:47:47 2008
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 2 Seq 1666730 Reading mem 0
Mem# 0 errs 0: /home2/oracle/app/oracle/oradata/jjit/redo02.log
Wed Oct 29 09:47:47 2008
Thread recovery: finish rolling forward thread 1
Thread recovery: 0 data blocks read, 0 data blocks written, 200 redo blocks read
Crash recovery completed successfully
Wed Oct 29 09:47:47 2008
Thread 1 advanced to log sequence 1666731
Thread 1 opened at log sequence 1666731
Current log# 3 seq# 1666731 mem# 0: /home2/oracle/app/oracle/oradata/jjit/redo03.log
Successful open of redo thread 1.
Wed Oct 29 09:47:47 2008
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Oct 29 09:47:49 2008
Errors in file /home2/oracle/app/oracle/admin/jjit/udump/ora_1674.trc:
Wed Oct 29 09:47:50 2008
Errors in file /home2/oracle/app/oracle/admin/jjit/udump/ora_1674.trc:
Wed Oct 29 09:47:50 2008
Errors in file /home2/oracle/app/oracle/admin/jjit/udump/ora_1674.trc:
Wed Oct 29 09:48:02 2008
Starting ORACLE instance (normal)
Wed Oct 29 09:48:19 2008
alter database open
Wed Oct 29 09:48:19 2008
Beginning crash recovery of 1 threads
Wed Oct 29 09:48:19 2008
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 3 Seq 1666731 Reading mem 0
Mem# 0 errs 0: /home2/oracle/app/oracle/oradata/jjit/redo03.log
Wed Oct 29 09:48:19 2008
Thread recovery: finish rolling forward thread 1
Thread recovery: 0 data blocks read, 0 data blocks written, 0 redo blocks read
Crash recovery completed successfully
Wed Oct 29 10:03:48 2008
Errors in file /home2/oracle/app/oracle/admin/jjit/udump/ora_1790.trc:
ORA-00600: 内部错误代码，自变量: , , [], [], [], [], [], []
ORA-600 signalled during: alter database open...
楼层
经过多次重启之后，系统又出现open能够打开，但是过不久之后又被自动关闭了，连所有进程都被crash了！
经过查看SCN，发现
日志组的scn分别是（10431456212412、10431456192272、10431460134089） 现在。 V$log的first_change#
数据库的是：10431456212413 v$database的checkpoint_change#。
库文件的是：10414729178608 v$datafile的checkpoint_change#，这个数字远远小于其他两个数字。
此时我该如何恢复呢？备注是在非归档模式下的，现在只想让数据库起来，能备份多少备份多少。
我把两个明显有错误的给offline drop了，这么估计是其他online的文件有坏块？
因为我多次的进行了文件的copy都没有发现问题。
是不是逻辑上的坏块？对于os来说是正常，但是对于oracle是坏块？
我先前倒是想过用dbv，但是看到数据库没有报告文件错误，所以就没进一步去检查。
页:
[1]