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

在recover datafile的过程当中如果丢失了需要的归档将使得recover无法进行,使用bbed工具可以跳过丢失的归档进行recover datafile。

实验过程如下:

[email protected]>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

[email protected]>create tablespace bbed_test_tbs

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

Tablespace created.

[email protected]>create table bbed_test1 tablespace bbed_test_tbs as select * from dba_objects;

Table created.

[email protected]>create table bbed_test2 tablespace bbed_test_tbs as select * from dba_objects;

Table created.

[email protected]>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

[email protected]>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

[[email protected] 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中存储的数据

[email protected]>delete from bbed_test1;

50316 rows deleted.

[email protected]>commit;

Commit complete.

[email protected]>alter system switch logfile;

System altered.

[email protected]>alter system switch logfile;

System altered.

[email protected]>alter system switch logfile;

System altered.

然后关闭数据库删除datafile 6

[email protected]>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

[[email protected] 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

[[email protected] ORCL]$ mv bbed_test_tbs01.dbf bbed_test_tbs01.dbf.bak

启动数据库:

[email protected]>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

[email protected]>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

[[email protected] archivelog]$ cd 2014_06_19/

[[email protected] 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

[[email protected] 2014_06_19]$ rm -f *

[[email protected] 2014_06_19]$ ls

[email protected]>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出文件头:

[email protected]>alter session set events ‘immediate trace name file_hdrs level 10‘;

Session altered.

[email protected]>[email protected]>oradebug setmypid;

Statement processed.

[email protected]>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,尝试打开数据库。

[email protected]>recover datafile 6;

Media recovery complete.

[email protected]>alter database open;

Database altered.

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

时间: 2024-10-05 18:10:29

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

使用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

Oracle number类型查询精度丢失的解决方法

Oracle number类型查询时,有时候会遇到精度丢失的问题,下面为您介绍了一个解决Oracle number类型查询精度丢失的方法,供您参考. 一.Oracle number类型查询需求中要求查到一个字段的值然后保持小数点后2位//如果采用如下方法从ResultSet得到一个数字,而这个数字大于40000,则得到的数据将不准确 floatzcxxhj+=rss.getFloat(3); //而如果采用double就没有问题 doublezcxxhj+=rss.getDouble(3); /

跳过丢失归档进行恢复

在我们恢复的时候,发现中间缺失归档,大部分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

BBED跳过归档恢复

实验: (1)备份5号文件SQL> select * from v$dbfile; FILE# NAME---------- ----------------------------------- 4 /orcl_backup/cold/users01.dbf 3 /orcl_backup/cold/undotbs01.dbf 2 /orcl_backup/cold/sysaux01.dbf 1 /orcl_backup/cold/system01.dbf 5 /orcl_backup/cold

Oracle在线 redo log文件丢失后的恢复

今天一个开发库启动不了了,发过来报错一看是日志文件损坏了(见下图),接着说了一下前因后果.说是年前服务器掉电了,然后就再没有启动起来过.今天有人用才想到要处理. 先说一下大体的思路,如果损坏的redo log是INACTIVE状态的,也就是实例崩溃恢复用不到的redo log,那处理起来比较容易,直接alter database clear logfile group #;或alter database clear unarchived logfile group #;重建日志组就行了.建议重建

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

在实际开发过程中,有时我们很有可能需要某个表的操作痕迹,或通过记录的SQL语句进行有目的性的数据恢复(此时POINT-IN-TIME恢复已经满足不了更细的粒度).或仅仅是查看: 据说Oracle8i之后,就提供了Logminer日志分析工具,虽然没有GUI图形化的界面,但也阻挡不了使用他的决心. Oracle11g下使用的情况: (1).数据库开启归档模式 在安装Logminer之前,我们先讲数据库设置为归档模式: 注意:如果开启日志分析功能,仅仅是分析系统默认的Redo01.log.Redo0

站点映射到外网踩到的坑,跳转丢失端口

今天准备的线上演示版本,把端口映射到外网后,发现跳转不正确,丢失了端口. 环境:centos7+docker 方案尝试: 1.修改docker的端口映射,直接把nginx的端口改为外网的端口.改完之后,大部分连接好用,还有个别链接不好用.方案被pass. 2.我们的nginx的原来配置有这么一行:proxy_set_header Host             $host; 我查看了nginx的文档,有这么一段说明 : 如果不想改变请求头"Host"的值,可以这样来设置: proxy

Oracle+ASM单机环境下,开启归档的最简单的方法

在ASM单机环境下,开启归档的最简单的方法.环境:oracle11g  11.2.0.4 登陆sqlplus[[email protected] ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Jun 8 18:20:41 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to an idle instance.

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

Oracle Database 12c中引入了 In-Database Archiving的新特性, 该特性允许用户通过对表上的数据行标记为inactive不活跃的,以归档数据. 这些inactive的数据行可以通过压缩进一部优化,且对应用来说默认不可见.该特性可以对现有代码做最少改动的情况下,实现了这种"标记删除"的功能和需求. 12c之前:有些应用有"标记删除"的概念,即不是删除数据,而是数据依然保留在表中,只是对应用不可见而已.这种需求通常通过如下方法实现:1