在recover datafile的过程其中假设丢失了须要的归档将使得recover无法进行。使用bbed工具能够跳过丢失的归档进行recover datafile。

实验步骤例如以下:

SYS@ORCL>select * from v$version;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE    10.2.0.1.0      Production

TNS for Linux: Version 10.2.0.1.0 - Production

NLSRTL Version 10.2.0.1.0 - Production

SYS@ORCL>create tablespace bbed_test_tbs

2  datafile '/u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf' size 20M;

Tablespace created.

SYS@ORCL>create table bbed_test1 tablespace bbed_test_tbs as select * from dba_objects;

Table created.

SYS@ORCL>create table bbed_test2 tablespace bbed_test_tbs as select * from dba_objects;

Table created.

SYS@ORCL>archive log list

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     2

Next log sequence to archive   4

Current log sequence           4

SYS@ORCL>select file#||' '||name||' '||bytes from v$datafile;

FILE#||''||NAME||''||BYTES

--------------------------------------------------------------------------------

1 /u01/app/oracle/oradata/ORCL/system01.dbf 503316480

2 /u01/app/oracle/oradata/ORCL/undotbs01.dbf 36700160

3 /u01/app/oracle/oradata/ORCL/sysaux01.dbf 262144000

4 /u01/app/oracle/oradata/ORCL/users01.dbf 5242880

5 /u01/app/oracle/oradata/ORCL/example01.dbf 104857600

6 /u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf 20971520

6 rows selected.

使用rman备份datafile 6

[oracle@jp bbed]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Jun 19 21:33:16 2014

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1356549586)

RMAN> backup datafile 6;

Starting backup at 19-JUN-14

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=143 devtype=DISK

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00006 name=/u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf

channel ORA_DISK_1: starting piece 1 at 19-JUN-14

channel ORA_DISK_1: finished piece 1 at 19-JUN-14

piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2014_06_19/o1_mf_nnndf_TAG20140619T213426_9t73x2s8_.bkp tag=TAG20140619T213426 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

Finished backup at 19-JUN-14

然后在库里改动datafile 6中存储的数据

SYS@ORCL>delete from bbed_test1;

50316 rows deleted.

SYS@ORCL>commit;

Commit complete.

SYS@ORCL>alter system switch logfile;

System altered.

SYS@ORCL>alter system switch logfile;

System altered.

SYS@ORCL>alter system switch logfile;

System altered.

然后关闭数据库删除datafile 6

SYS@ORCL>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@jp ORCL]$ ls

bbed_test_tbs01.dbf  control03.ctl  redo02.log    system01.dbf   users01.dbf

control01.ctl        example01.dbf  redo03.log    temp01.dbf

control02.ctl        redo01.log     sysaux01.dbf  undotbs01.dbf

[oracle@jp ORCL]$ mv bbed_test_tbs01.dbf bbed_test_tbs01.dbf.bak

启动数据库:

SYS@ORCL>startup

ORACLE instance started.

Total System Global Area  285212672 bytes

Fixed Size                  1218992 bytes

Variable Size              83887696 bytes

Database Buffers          197132288 bytes

Redo Buffers                2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf'

数据库无法启动由于此时datafile 6丢失,使用rman的备份恢复数据文件,尝试打开数据库

RMAN> restore datafile 6;

Starting restore at 19-JUN-14

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=155 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00006 to /u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf

channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/ORCL/backupset/2014_06_19/o1_mf_nnndf_TAG20140619T213426_9t73x2s8_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2014_06_19/o1_mf_nnndf_TAG20140619T213426_9t73x2s8_.bkp tag=TAG20140619T213426

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 19-JUN-14

SYS@ORCL>alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 6 needs media recovery

ORA-01110: data file 6: '/u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf'

此时报datafile 6须要进行recover。

这时我们删除归档。然后尝试recover datafile 6

[oracle@jp archivelog]$ cd 2014_06_19/

[oracle@jp 2014_06_19]$ ls

o1_mf_1_3_9t73hdco_.arc  o1_mf_1_5_9t740dxd_.arc

o1_mf_1_4_9t74035o_.arc  o1_mf_1_6_9t740sv7_.arc

[oracle@jp 2014_06_19]$ rm -f *

[oracle@jp 2014_06_19]$ ls

SYS@ORCL>recover datafile 6;

ORA-00279: change 507768 generated at 06/19/2014 21:34:26 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2014_06_19/o1_mf_1_4_%u_.arc

ORA-00280: change 507768 for thread 1 is in sequence #4

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

ORA-00308: cannot open archived log

'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2014_06_19/o1_mf_1_4_9t7403

5o_.arc'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

无法恢复。提示须要的归档文件不存在

Dump出文件头:

SYS@ORCL>alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

SYS@ORCL>SYS@ORCL>oradebug setmypid;

Statement processed.

SYS@ORCL>oradebug tracefile_name

/u01/app/oracle/admin/ORCL/udump/orcl_ora_9065.trc

查看dump文件:

DATA FILE #1:

(name #7) /u01/app/oracle/oradata/ORCL/system01.dbf

creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:56 scn: 0x0000.0007c39c 06/19/2014 21:37:19

Stop scn: 0x0000.0007c39c 06/19/2014 21:37:19

Creation Checkpointed at scn:  0x0000.00000009 06/30/2005 19:10:11

thread:0 rba:(0x0.0.0)

这时system数据文件的,然后我们使用bbed将datafile 6的scn和system数据文件的scn改为一致。

BBED> set dba 6,1

DBA             0x01800001 (25165825 6,1)

BBED> map

File: /u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf (6)

Block: 1                                     Dba:0x01800001

------------------------------------------------------------

Data File Header

struct kcvfh, 676 bytes                    @0

ub4 tailchk                                @8188

BBED> p kcvfhckp

struct kcvfhckp, 36 bytes                   @484

struct kcvcpscn, 8 bytes                 @484

ub4 kscnbas                           @484      0x0007bf78

ub2 kscnwrp                           @488      0x0000

ub4 kcvcptim                             @492      0x32b46ee2

ub2 kcvcpthr                             @496      0x0001

union u, 12 bytes                        @500

struct kcvcprba, 12 bytes             @500

ub4 kcrbaseq                       @500      0x00000004

ub4 kcrbabno                       @504      0x0000a54a

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> m /v 9cc3 offset 484

BBED-00201: invalid switch (/v)

BBED> m /x 9cc3 offset 484

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y

File: /u01/app/oracle/oradata/ORCL/bbed_test_tbs01.dbf (6)

Block: 1                Offsets:  484 to  995           Dba:0x01800001

------------------------------------------------------------------------

9cc30700 0000e7b7 e26eb432 0100f50d 04000000 4aa50000 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

0a000a00 0a000100 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 = 0x862e, required = 0x862e

然后回到数据库recover datafile 6,尝试打开数据库。

SYS@ORCL>recover datafile 6;

Media recovery complete.

SYS@ORCL>alter database open;

Database altered.

【Oracle】使用BBED跳过丢失的归档的更多相关文章

  1. 使用BBED跳过归档进行恢复

    https: 使用BBED跳过归档进行恢复 数据库启动异常,提示6号文件丢失 SQL> startup ORACLE instance started. Total System Global ...

  2. 05 使用bbed跳过归档恢复数据文件

    5 使用BBED跳过归档 在归档模式下,缺失了一部分的归档日志文件,对数据文件进行恢复 1 开启归档 --shutdown immediate --startup mount --alter data ...

  3. BBED跳过归档

    通过BBED 跳过归档,以当前数据库 8号文件为例: SQL; FILE# NAME ---------- ---------------------------------------------- ...

  4. oracle flashback data archive闪回数据归档天坑之XID重用导致闪回查询数据重复

    我们有个系统使用了Oracle flashback data archive闪回数据归档特性来作为基于时间点的恢复机制,在频繁插入.更新期间发现SYS_FBA_HIST_NNNN表中的XID被两个事务 ...

  5. oracle闪回、闪回数据归档Flashback Data Archive (Oracle Total Recall)的真正强大之处、11gR2增强以及合理使用

    oracle的闪回很早就出来了,准确的说一直以来应该都较少被真正用户广为使用,除了dba和极少部分开发人员偶尔用于逻辑出错.误删恢复之外,较少被用于产生更有价值的用途. 各种闪回表flashback ...

  6. Oracle Logminer 分析重做日志RedoLog和归档日志ArchiveLog

    在实际开发过程中,有时我们很有可能需要某个表的操作痕迹,或通过记录的SQL语句进行有目的性的数据恢复(此时POINT-IN-TIME恢复已经满足不了更细的粒度).或仅仅是查看: 据说Oracle8i之 ...

  7. jsp/servlet页面跳转丢失样式问题

    问题:使用servlet,如何处理在多路径页面跳转中servlet转发页面样式丢失问题?(例如访问 http://localhost/project/listUser.action后转到http:// ...

  8. Oracle数据库体系结构(6)数据库归档重做日志文件管理

    归档重做日志文件的概念和选择 Oracle数据库能够把已经写满了的重做日志文件保存到一个或多个指定的离线位置,这种保存的文件为归档重做日志文件.通常情况下一个归档重做日志时一个被LGWR写满的重做日志 ...

  9. Oracle 12c 新特性之 数据库内归档(In-Database Archiving)

    Oracle Database 12c中引入了 In-Database Archiving的新特性, 该特性允许用户通过对表上的数据行标记为inactive不活跃的,以归档数据. 这些inactive ...

随机推荐

  1. Python的程序结构[1] -> 方法/Method[0] -> 类实例方法、私有方法和抽象方法

    类实例方法.私有方法和抽象方法 Python中最常用的就是类实例方法,类似于属性中的类实例属性,同时,也存在与私有属性类似方法,即私有方法,下面介绍这两种常见的方法,以及一种特殊意义的类实例方法 -- ...

  2. 新疆大学ACM-ICPC程序设计竞赛五月月赛(同步赛)- 杨老师的游戏

    链接:https://www.nowcoder.com/acm/contest/116/B来源:牛客网 题目描述 杨老师给同学们玩个游戏,要求使用乘法和减法来表示一个数,他给大家9张卡片,然后报出一个 ...

  3. ssh框架整合shiro权限

    关于整合shiro,首先在ssh整合的基础上进行组合 1.首先,要导入几个依赖(整合ssh与shiro的依赖): <properties><shiro.version>1.3. ...

  4. 安裝jpeg-6b png error错误解决方法

    安裝jpeg-6b png error错误解决方法 默认安裝jpeg-6b shell> wget ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar. ...

  5. easyui combogrid 按需加载,点击下拉加载

    功能优点:减少不必要的http请求,减少服务器查询压力,降低额外的浏览器渲染,提高呈现速度开发分享: combogrid 点击才请求的功能实现简要:我分析了费用系统,和现在全网的写法.并不满意.都是要 ...

  6. SQL Server 2017 EXPRESS 安装 SQLCMD 设置远程连接

    1.配置管理器内启动TCP/IP协议(端口改为1433)以及加入防火墙允许 2.进入本地实例: cmd Microsoft Windows [版本 ] (c) Microsoft Corporatio ...

  7. ASIHTTPRequest学习(三)

    刚刚开始学习ASIHttpRequest,今天通过自己写的一个小demo分享一下学习心得. 首先,要想在ios项目中使用ASIHttpRequest,必须添加下列框架和类库: ASIHttpReque ...

  8. [Android Traffic] 使用缓存来避免重复的下载

    转载自: http://blog.csdn.net/kesenhoo/article/details/7395817 Redundant Downloads are Redundant[重复下载是冗余 ...

  9. GTK+重拾--09 GTK+中的组件(一)

    (一):写在前面 在这篇文章中主要介绍了GTK+程序中的各种构件,这是解说构件的第一个部分,另外一部分将在下一个小节中讲到. 构件是建立一个GUI程序的基础.在GTK+的长期发展过程中.一些特定的构件 ...

  10. 我与小娜(36):人机大战第五局,AlphaGo必胜!

    我与小娜(36):人机大战第五局,AlphaGo必胜!       小娜知道,细致阅读论文"Mastering the game of Go with deep neural network ...