跳过丢失归档进行恢复

在我们恢复的时候，发现中间缺失归档，大部分dba认为从缺失的归档开始以后的归档都无法进行恢复。但是我们从非常规的方式，修改数据文件对应的信息是可以跳过该缺失的归档，并且利用后面的归档进行恢复的。

[email protected]>recover datafile 6;
ORA-00279: change 2054392 generated at 10/28/2014 23:20:14 needed for thread 1
ORA-00289: suggestion : /opt/oracle/flash_recovery_area/ORCL11G/archivelog/2014_10_28/o1_mf_1_150_b50rqvq8_.arc
ORA-00280: change 2054392 for thread 1 is in sequence #150

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00326: log begins at change 2055246, need earlier change 2054392
ORA-00334: archived log: '/opt/oracle/flash_recovery_area/ORCL11G/archivelog/2014_10_28/o1_mf_1_150_b50rqvq8_.arc'

这里我们发现对应的归档文件已经丢失，无法进行恢复

这里我们通过bbed只需要修改两个地方即可跳过该归档，使用下一个归档进行恢复：

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484
   struct kcvcpscn, 8 bytes                 @484
      ub4 kscnbas                           @484      0x001f58f8
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x3363df2e
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500
      struct kcvcprba, 12 bytes             @500
         ub4 kcrbaseq                       @500      0x00000095
         ub4 kcrbabno                       @504      0x00000002
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED> modify /x 96 offset 500
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /opt/oracle/oradata/orcl11g/zbdba01.dbf (6)
Block: 1                Offsets:  500 to 1011           Dba:0x01800001
------------------------------------------------------------------------
96000000 02000000 10000000 02000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 0d000d00 0d000100 00000000 00000000
00000000 02008001 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply
Check value for File 6, Block 1:
current = 0x6ce1, required = 0x6ce1

BBED> verify
DBVERIFY - Verification starting
FILE = /opt/oracle/oradata/orcl11g/zbdba01.dbf
BLOCK = 1

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

BBED> show all
        FILE#           6
        BLOCK#          1
        OFFSET          500
        DBA             0x01800001 (25165825 6,1)
        FILENAME        /opt/oracle/oradata/orcl11g/zbdba01.dbf
        BIFILE          bifile.bbd
        LISTFILE        filelist.txt
        BLOCKSIZE       8192
        MODE            Edit
        EDIT            Unrecoverable
        IBASE           Dec
        OBASE           Dec
        WIDTH           80
        COUNT           512
        LOGFILE         log.bbd
        SPOOL           No

BBED> modify /x 1f5c4e offset 484
File: /opt/oracle/oradata/orcl11g/zbdba01.dbf (6)
Block: 1                Offsets:  484 to  995           Dba:0x01800001
------------------------------------------------------------------------
1f5c4e00 00000000 2edf6333 01000000 96000000 02000000 10000000 02000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0d000d00 0d000100 00000000 00000000 00000000 02008001 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply
Check value for File 6, Block 1:
current = 0x6857, required = 0x6857

BBED> verify
DBVERIFY - Verification starting
FILE = /opt/oracle/oradata/orcl11g/zbdba01.dbf
BLOCK = 1

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

再次进行恢复：

[email protected]>
[email protected]>
[email protected]>recover datafile 6;
Media recovery complete.
[email protected]>
[email protected]>
[email protected]>
[email protected]>
[email protected]>alter database datafile 6 online;

Database altered.

在生产环境不到万不得已，请勿效仿

时间： 2024-07-30 13:31:02

跳过丢失归档进行恢复的相关文章

【Oracle】使用BBED跳过丢失的归档

在recover datafile的过程当中如果丢失了需要的归档将使得recover无法进行,使用bbed工具可以跳过丢失的归档进行recover datafile. 实验过程如下: [email protected]>select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Rele

使用BBED跳过归档进行恢复

https://blog.csdn.net/gumengkai/article/details/53311390 使用BBED跳过归档进行恢复数据库启动异常,提示6号文件丢失 SQL> startup ORACLE instance started. Total System Global Area 776646656 bytes Fixed Size 2257272 bytes Variable Size 490737288 bytes Database Buffers 281018368

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE

ORACLE数据库文件丢失后的恢复测试

一.测试环境数据库版本是11GR2,在做完一份完全备份之后,关机,做一份快照,每一次开机之后都执行数次alter system switch logfile以产生归档日志. 之后的测试都是基于这么一个完全备份来恢复. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F'; backup incremental level 0 format '/backup/%T_%f' database; 二.

OracleDG主库丢失归档增量同步

1.1 问题在主库archivelog丢失后,数据无法同步到备库时,可以利用增量scn的方式,来避免全库还原备库或重建standby 以下在Oracle10g下操作 1.2 当前正常主备确认当前主库与备库是同步的: 1.2.1 主库 SQL> SELECT database_role FROM v$database; DATABASE_ROLE ---------------- PRIMARY SQL> set linesize 200 pagesize 200 SQL&

IOS中利用NSKeyedArchiver进行数据的归档和恢复

1.相关知识点: <1> 可以利用NSKeyedArchiver 进行归档和恢复的对象类型:NSString .NSDictionary.NSArray.NSData. NSNumber等 <2> 使用是必须遵循NSCoding协议对象,实现两个方法: encodeWithCoder:归档对象时,将会调用该方法. initWithCoder:每次从文件中恢复对象时,调用该方法. 2.简单例子阐述详细步骤 <1> 创建一个学生

MyISAM表的.frm文件丢失后的恢复方法

MyISAM表的.frm文件丢失后的恢复方法: 1.创建实验用的MyISAM表t1,并插入数据: mysql> create table t1(id int) engine=myisam; Query OK, 0 rows affected (0.01 sec) mysql> insert into t1 values(1),(2),(3),(4),(5),(6),(7),(8); Query OK, 8 rows affected (0.00 sec) Records: 8 Duplica

分区丢失了如何恢复？

很多时候,因为一些误操作导致分区突然丢失或者无缘无故分区就丢失了.这时候只要采取正确的方法恢复数据就可以完整的找回数据恢复.曙光数据恢复软件中有个分区丢失数据恢复专门恢复分区丢失情况的. 我这里有块硬盘分区全部不见了在磁盘管理中是一块未初始化的2T硬盘.下面用曙光数据恢复软件对这块硬盘进行恢复. 第一步自然是打开数据恢复软件,选择分区丢失数据恢复第二步:选择需要恢复的物理磁盘, 第三步:等待扫描完成,由于硬盘有点大所以需要点时间. 等出现下面提示就表示扫描完成了第四步:双击目录展开第五步

iOS开发 - 数据归档与恢复 NSKeyedArchiver

归档与恢复归档归档,英文Archiver['ɑrk?v?],这里指的是将OC的对象存储为一个文件或者网络上的一个数据块. 恢复归档.英文UnArchiver,指的是将一个来自文件或网络的归档数据块恢复成内存中的一个OC对象. 归档和恢复主要用于对自己定义类型对象进行存储.在程序暂停或关闭前保存自己定义数据.在程序又一次恢复状态或启动后读取存储的自己定义数据. 支持归档和恢复的类必须实现NSCoding协议,再由NSKeyedArchiver和NSKeyedUnarchiver类进行转换.将对象