Chinaunix首页 | 论坛 | 博客
  • 博客访问: 92412266
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: Oracle

2008-04-16 13:37:10

     来源:赛迪网    作者:Alizze

创建备份后,在关闭数据库之前,备份一下控制文件:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;

然后打开备份的控制文件,删除第一个#之上的所有行,并删除“RECOVER DATABASE…”到文件结尾的全部。

第2步:转储丢失的数据库文件备份并应用日志;

这一步应该转储备份,并应用日志到直到无法在前向滚动,此时如果尝试正常打开数据库,将会得到ORA-01589: must use RESETLOGS or NORESETLOGS option for database open错误。

如果尝试执行ALTER DATABASE OPEN RESETLOGS,将会得到ORA-01195错误:ORA-01195: online backup of file %s needs more recovery to be consistent。

这里是Oracle使用其硬线路的位置。由于转储的数据文件不能恢复到与其他文件一致的位置,所以可能存在中断的数据并且Oracle不允许正常打开数据库。

第3步:设置未文档化的实例参数并打开数据库

在初始化参数文件中首先需要将job_queue_processes设置为0,然后设置_allow_resetlogs_corruption=TRUE,更改该参数后,切换到保存新控制文件的目录,第一步创建的位置。然后以SYSDBA连接并运行新的控制文件创建脚本。

此时数据库可以打开了。

SQL> SELECT COUNT(*) FROM OE.orders;

第4步:执行导出并提取数据

在这一步可以很容易的看到那些表导出了全部的数据。

第5步:转储备份的数据库

这一步,以及下面两步可选。这三步结合在一起允许提取更多的数据,这一步从备份的数据库转储可以高效的撤销任何由于使用_allow_resetlogs_corruption参数造成的毁坏。因此,这一步不会恢复任何丢失的数据文件。

第6步:使毁坏的数据文件offline

ALTER DATABASE DATAFILE '/u07/oradata/PRD/ordtab03.dbf' OFFLINE;

这一步得到数据库的完全一致性状态。

第7步:执行导出并提取额外的数据

这一步可能能够提取从第四步不能提取的额外数据,如索引中的数据。

第8步 :转储数据库

这是最后一次转储数据库,这一步正式回滚数据库到使用隐含参数前那一刻,然后将数据库返回到正常状态,如果从第五步转储以来没有更新任何数据,可以跳过这一步。

第9步:删除有问题的表空间

首先需要查看是否有完整性约束限制,使用以下查询:

SELECT CR.constraint_name

FROM dba_constraints CR, dba_constraints CP, dba_tables TP, dba_tables TR

WHERE CR.r_owner = CP.owner

AND CR.r_constraint_name = CP.constraint_name

AND CR.constraint_type = 'R'

AND CP.constraint_type IN ('P', 'U')

AND CP.table_name = TP.table_name

AND CP.owner = TP.owner

AND CR.table_name = TR.table_name

AND CR.owner = TR.owner

AND TR.tablespace_name <> 'ORDTAB'

AND TP.tablespace_name = 'ORDTAB';

如果有约束,可能需要创建重建脚本。如果使用export dump重建数据,约束可以从导出文件转储。

DROP TABLESPACE ordtab INCLUDING CONTENTS CASCADE CONSTRAINTS;

第10步:重建表空间

第11步:重建数据

执行导入后,结束。

阅读(302) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~