丢失归档日志文件后数据库应当如何恢复

运维 数据库运维
在数据库操作过程中,数据库中数据的丢失是经常会发生的,由于数据库中数据信息的重要性,又不得不将其找回来,那么如何将丢失归档文件恢复呢?

导读:本文主要介绍了如何从一个不能正常打开的数据库(由于一个/多个数据库文件与其他文件不一致)中提取数据的具体示例,然后通过这个例子来给大家详细分析丢失归档日志文件恢复

  具体案例:

  一个磁盘损坏了并且丢失了一个数据库文件。从一周前的热备转储数据文件,可是丢失了几个归档日志文件。但是有问题的数据文件包含了最重要的表,采用什么办法才能挽救数据呢?

  解决方法:

  每个数据库管理员都知道这是有问题的,一定会丢失数据,因为某些事务丢失了,问题是会丢失多少数据?Oracle使用硬线路位置并且由于存在完整性约束问题,因此不允许正常打开数据。但是如果使用非常规的方法让Oracle删除其硬线路属性,那么应该能够提取尽可能多的数据。而通常这会比损失全部数据要好很多。

  通常假如仅仅丢失了堆表的索引,或者某些能够很容易重建的数据,那么最好的方法应该是删除表空间并重建这些对象然后重新输入。但是如果丢失的数据文件包含了重要数据并且很难恢复,而且只有前一次的备份却又丢失了某些归档日志,那么用户可能希望能够尽可能多的从有问题的表空间恢复数据并且删除和重建表空间。

  具体步骤如下:

  1.对当前拥有的数据进行一个冷备;

  2.转储丢失的数据库文件备份并应用可以应用的日志;

  3.设置未文档化的初始化参数,其允许你在当前状态打开数据库;

  4.执行exp并提取全部可以从有问题的表空间提取的数据;

  5.从先前的冷备转储数据库;

  6.使毁坏的数据文件offline;

  7.执行exp并提取第4步没有提取的额外数据;

  8.在一次从冷备转储;

  9.删除有问题的表空间;

  10.重建有问题的表空间;

  11.使用第四步和第七步提取的数据重建数据;

  使用案例描述:ORDTAB表空间的一个数据文件ordtab03.dbf毁坏,其包含很多

  ORDERS表的分区,数据文件热备于July 4, 2004,July 4—至今的某些归档日志丢失。

#p#

  第1步:备份数据库

  第1步的任务是冷备当前拥有的任何数据文件,在线重做日志,和控制文件。如果丢失了一个/多个数据文件但是数据库仍然是open的,那么对每个剩余的数据文件进行热备并确保备份期间/之后的归档被安全保存。

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

  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步:重建数据

  执行导入后,结束。

上文中深入讲解了丢失归档日志文件的丢失的恢复方法,相信大家在以后遇到类似的问题,自己就能轻松解决,大家都要熟练掌握哦,希望能够对大家有所帮助。

【编辑推荐】

  1. 数据库中利用角色增强应用系统安全
  2. 讲解Oracle数据库提供的多种安全性措施
  3. 如何恢复数据库的内容
责任编辑:迎迎 来源: 希赛网
相关推荐

2011-05-24 10:26:12

Oracle数据库日志文件

2010-11-19 13:28:13

2010-06-09 15:40:59

MySQL数据库文件

2017-06-14 21:31:39

数据库Oracleresetlogs

2011-08-02 11:16:08

Oracle数据库归档日志

2010-07-20 15:01:39

SQLServer日志

2010-08-27 11:22:01

DB2日志文件归档

2011-03-04 14:59:16

Raidoracle数据库

2011-08-23 17:45:54

MySQL丢失root密码

2018-04-28 15:28:44

数据库MySQL误删除

2010-05-14 14:21:18

2019-08-20 14:02:07

MongoDB数据库恢复数据

2010-07-01 12:44:52

SQL Server数

2011-08-01 13:28:09

Oracle归档模式非归档模式

2018-04-28 14:55:41

Windows 10升级恢复

2011-05-13 13:26:52

master数据库恢复

2011-03-24 11:14:46

2011-03-22 16:20:19

恢复数据库

2017-10-16 16:43:05

数据库Oracle数据丢失

2011-07-15 15:55:50

SQL Server日附加数据库
点赞
收藏

51CTO技术栈公众号