Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2017-4-16 13:54:17 | 查看: 1411| 回复: 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,但是看到数据库没有报告文件错误,所以就没进一步去检查。
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-5-19 07:51 , Processed in 0.044654 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569