oracle特殊恢复相关书籍,总结:一次特殊的数据库恢复

总结:一次特殊的数据库恢复

为啥叫特殊的数据库恢复,因为这个数据库no backup、no archivelog 甚至用户连数据文件、控制文件等等放在哪都不知道,我想大家不一定有类似痛苦的经历吧,正好上周俺处理了一个这种案例,拿出来总结与大家分享一下。

时间:2009-9-18

地方:某大型事业单位

起因:很旧的机器alpha1(多少来着,不记得了,内存是512M!)与raid5组成配置,oracle与操作系统装在raid5上(很怪的配置方案,不知道怎么规划的),因为os所在的硬盘故障(幸好oracle那块盘没有坏),需要将oracle恢复到alpha1上。

之前发过一个帖子:

http://www.itpub.net/viewthread. ... light=%2Blixiang114

任务:一、在alpha1上重装oracle数据库

二、试图恢复因为磁盘故障造成的数据库down机

OS: Tru64 5.1(靠,补丁找了好半天)

DB: Oracle 9201

alpha1挂好硬盘后装上Tru64 5.1打好补丁、装上了oracle、创建好实例后,想要copy原数据文件的时候被用户告知不知道数据文件放哪里,自从2002年后没有碰过这个数据库,顿时无语。。。所幸控制文件和pfile被我找到了,还好可以startup nomount、 alter database mount,然后确认了下redolog、datafile后将这些东西都copy了回来,直接alter database open,接着一连串的ora-600出现了。。。

一 ORA-600 [kcratr1_lostwrt], [], [], [], [], [], [], []

SQL>alter database open

ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], []

看了下alert日志google了一下,

可以使用recover database 尝试恢复一下,

SQL>recover database

ora-00283 recovery session canceled due to errors

………………..

二  ORA-00600: internal error code, arguments: [3020], [8388713], [1], [157], [4], [16], [], []

接着看alert日志

ORA-00600: internal error code, arguments: [3020], [8388713], [1], [157], [4], [16], [], []

ORA-10567: Redo is inconsistent with data block (file# 2, block# 105)

ORA-10564: tablespace UNDOTBS1

ORA-01110: data file 2: '/oracle/ora9/undotbs01.dbf'

ORA-10560: block type 'KTU SMU HEADER BLOCK'

Errors with log .

Media Recovery failed with error 600

ORA-283 signalled during: ALTER DATABASE RECOVER  database  ...

应该是恢复的时候需要用到UNDOTBS1,但是这个表空间不可用了,导致recover错误。

想起了使用_ALLOW_RESETLOGS_CORRUPTION隐含参数,可是该参数在当前redolog损坏、没有备份、没有归档的时候使用,只是后2条满足我的环境,。current redo是可用的,没办法,实在没有别的办法了,只有硬着头皮试试了。

SQL> ALTER SYSTEM SET "_allow_resetlogs_corruption"=TRUE SCOPE=SPFILE;

SQL>shutdown immediate

SQL>startup mount

SQL>recover database using backup controlfile until cancel;

SQL>alter database open resetlogs

………….

等了很久

………..

ORA-03313:end-of-file on communication channel

三 ORA-00600: internal error code, arguments: [2662], [0], [32281372], [0], [32366091], [8388617], [], []

再次查看alert日志:

Mon Sep 21 15:20:49 2009

Errors in file /usr/users/oracle/app/oracle/admin/ora9/udump/ora9_ora_21790.trc:

ORA-00600: internal error code, arguments: [2662], [0], [32281372], [0], [32366091], [8388617], [], []

Mon Sep 21 15:20:53 2009

Errors in file /usr/users/oracle/app/oracle/admin/ora9/udump/ora9_ora_21790.trc:

ORA-00600: internal error code, arguments: [2662], [0], [32281372], [0], [32366091], [8388617], [], []

Mon Sep 21 15:20:53 2009

Error 600 happened during db open, shutting down database

USER: terminating instance due to error 600

Instance terminated by USER, pid = 21790

ORA-1092 signalled during: alter database open resetlogs...

Mon Sep 21 15:25:53 2009

USER: terminating instance due to error 1092

Instance terminated by USER, pid = 21790

又报了个600新错误,,google下,

原来是伴随着ora600[3020]之后,出现的scn相关问题,对症下药

SQL> alter session set events '10015 trace name adjust_scn level 1';

观察ora600 第三、第五个参数分别是32281372、32366091相差不大,所以level 1足够

顽强的继续open

SQL>alter database open

ORA-01092:ORACLE instance terminated.Disconnection

重新开了个终端:

SQL>startup

依然是mounted

SQL>alter database open

ORA-1092 signalled during: alter database open...

还是顽强的看alert日志

Mon Sep 21 16:27:54 2009

Errors in file /usr/users/oracle/app/oracle/admin/ora9/bdump/ora9_smon_22354.trc:

ORA-00600: internal error code, arguments: [4193], [509], [512], [], [], [], [], []

出现的第四个ORA600 [4193]

不过这个600比较经典了,

是回滚段损坏的问题,似乎看到了一点曙光!!

观察完日志,接着修改pfile

SQL>create pfile=’/usr/user/oracle/pfile2009.ora’ from spfile

添加了

._corrupted_rollback_segments='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$','_SYSSMU4$','_SYSSMU5$','_SYSSMU6$','_SYSSMU7$','_SYSSMU8$','_SYSSMU9$','_SYSSMU10$'

SQL>shutdown immediate

SQL>startup pfile=’/usr/user/oracle/pfile2009.ora’;

SQL>recover database until cancel

Cancel

SQL>alter database open resetlogs

………

………

看到了

Instance opend

马上确认了下

SQL>select status from v$instance

open

长出了一口气,呼呼

然后按用户exp了库、imp到新库,检查应用、收工!!!NND!!

以上就是一次特殊的oracle恢复,没有backup真是受不了,用户有一个2002年的.dmp让我无语,不过能恢复确实需要一些运气了,最后引用eygle的一句话,备份终重于一切!!!

[本帖最后由 lixiang114 于 2009-9-25 14:59 编辑]

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值