- 最后登录
- 2017-5-4
- 在线时间
- 81 小时
- 威望
- 999
- 金钱
- 2391
- 注册时间
- 2013-9-11
- 阅读权限
- 150
- 帖子
- 1124
- 精华
- 5
- 积分
- 999
- UID
- 1220
|
1#
发表于 2017-4-16 13:54:17
|
查看: 1728 |
回复: 0
大概是这样的过程:
还是上次说的那个数据库,因为物理硬盘损坏,造成读不可靠。该损坏数据涉及到的表空间为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错误,后面代码是[3708][910]。我在网上查了一下该错误,所得的信息很少。
现在不知道下一步该怎么办,怕误操作造成更大的问题。我当时只考虑到对损坏的表空间进行备份,忘记了同步备份控制和日志文件以及系统表空间的文件。
请问大侠们,是不是因为控制文件和日志文件的不匹配造成这种错误?如果我忽略所有的日志文件的更改可不可以呢?谢谢各位大侠了!
在最后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: 内部错误代码,自变量: [3708], [910], [], [], [], [], [], []
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,但是看到数据库没有报告文件错误,所以就没进一步去检查。
|
|