【故障处理】DG环境主库丢失归档情况下数据文件的恢复（4）

本文主要是介绍【故障处理】DG环境主库丢失归档情况下数据文件的恢复（4），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

【故障处理】DG环境主库丢失归档情况下数据文件的恢复

BLOG文档结构图

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

2、修复文件头的scn号

编译完成后可以使用BBED了：

SYS@oraLHRD1> set line 9999 pagesize 9999

SYS@oraLHRD1> col name format a80

SYS@oraLHRD1> select file#||' '||name||' '||bytes name from v$datafile where file#=64;

NAME

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

64 +DATA1/oralhrs/datafile/tbs101.262.876578481 104857600

[ZFLHRSDB1:root]:/>su - grid

[ZFLHRSDB1:grid]:/home/grid>asmcmd

ASMCMD> cp +DATA1/oralhrs/datafile/tbs101.262.876578481 /tmp/a.dbf

copying +DATA1/oralhrs/datafile/tbs101.262.876578481 -> /tmp/a.dbf

ASMCMD> exit

[ZFLHRSDB1:grid]:/home/grid>exit

[ZFLHRSDB1:root]:/>su - oracle

[ZFLHRSDB1:oracle]:/oracle>vi /tmp/file.txt

[ZFLHRSDB1:oracle]:/oracle>cat /tmp/file.txt

1 /tmp/a.dbf

[ZFLHRSDB1:oracle]:/oracle>bbed PASSWORD=blockedit mode=edit blocksize=8192 listfile=/tmp/file.txt

BBED-00303: unable to open file '/tmp/a.dbf'

[ZFLHRSDB1:oracle]:/oracle>l /tmp/a.dbf

-rw-r----- 1 grid dba 104865792 Sep 20 17:07 /tmp/a.dbf

[ZFLHRSDB1:oracle]:/oracle>exit

[ZFLHRSDB1:root]:/>chown oracle.dba /tmp/a.dbf

[ZFLHRSDB1:root]:/>su - oracle

[ZFLHRSDB1:oracle]:/oracle>bbed PASSWORD=blockedit mode=edit blocksize=8192 listfile=/tmp/file.txt

BBED-00303: unable to open file 'log.bbd'

[ZFLHRSDB1:oracle]:/oracle>cd /tmp

[ZFLHRSDB1:oracle]:/tmp>bbed PASSWORD=blockedit mode=edit blocksize=8192 listfile=/tmp/file.txt

BBED: Release 2.0.0.0.0 - Limited Production on Tue Sep 20 17:11:28 2016

************* !!! For Oracle Internal Use only !!! ***************

BBED> info

File# Name Size(blks)

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

1 /tmp/a.dbf 0

BBED> show

FILE# 1

BLOCK# 1

OFFSET 0

DBA 0x00400001 (4194305 1,1)

FILENAME /tmp/a.dbf

BIFILE bifile.bbd

LISTFILE /tmp/file.txt

BLOCKSIZE 8192

MODE Edit

EDIT Unrecoverable

IBASE Dec

OBASE Dec

WIDTH 80

COUNT 512

LOGFILE log.bbd

SPOOL No

BBED> p kcvfhckp

struct kcvfhckp, 160 bytes @484

struct kcvcpscn, 8 bytes @484

====>>>>>kscnbas，这里是64号文件的当前SCN号，和之前查询来的是一致的，十进制为：1764555149

ub4 kscnbas @484 0x692cf98d

ub2 kscnwrp @488 0x0000

ub4 kcvcptim @492 0x342e3478

ub2 kcvcpthr @496 0x0002

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

====>>>>>kcrbaseq，这里是64号文件的当前日志号，468转换为十进制是1128

ub4 kcrbaseq @500 0x00000468

ub4 kcrbabno @504 0x0002c2fe

ub2 kcrbabof @508 0x0010

ub1 kcvcpetb[0] @512 0x06

ub1 kcvcpetb[1] @513 0x00

ub1 kcvcpetb[2] @514 0x00

《《《《。。。。。。。。篇幅原因，有省略。。。。。。。。》》》》

====》数据文件的scn被记录在文件1号block偏移量484字节开始的四个字节中

BBED> d /v dba 1,1 offset 484 count 64

File: /tmp/a.dbf (1)

Block: 1 Offsets: 484 to 547 Dba:0x00400001

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

692cf98d 00000000 342e3478 00020000 l i,......4.4x....

00000468 0002c2fe 00100001 06000000 l ...h............

00000000 00000000 00000000 00000000 l ................

<16 bytes per line>

====》AIX下存储是正序，这个和linux正好相反

BBED> modify /x 3ab645ab3 dba 1,1 offset 484

BBED-00209: invalid number (3ab645ab3)

BBED> modify /x ab647c08 dba 1,1 offset 484

BBED-00209: invalid number (ab647c08)

====》484号不能直接修改，因为ab647c08是以字母开头，必须以数字开头，那么我们从483号开始修改

BBED> modify /x 00ab647c dba 1,1 offset 483

File: /tmp/a.dbf (1)

Block: 1 Offsets: 483 to 546 Dba:0x00400001

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

00ab647c 7b000300 00342e34 78000200 0000002b 4f0002c2 fe000000 10060000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> modify /x 08 dba 1,1 offset 487

File: /tmp/a.dbf (1)

Block: 1 Offsets: 487 to 550 Dba:0x00400001

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

08000300 00342e34 78000200 0000002b 4f0002c2 fe000000 10060000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> d /v dba 1,1 offset 484 count 64

File: /tmp/a.dbf (1)

Block: 1 Offsets: 484 to 547 Dba:0x00400001

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

ab647c08 00030000 342e3478 00020000 l .d|.....4.4x....

00002b4f 0002c2fe 00000010 06000000 l ..+O............

00000000 00000000 00000000 00000000 l ................

<16 bytes per line>

BBED>

BBED> p kcvfhckp

struct kcvfhckp, 160 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas @484 0xab647c08

ub2 kscnwrp @488 0x0003 ====>>>日志号过大，所以用到了kscnwrp

ub4 kcvcptim @492 0x342e3478

ub2 kcvcpthr @496 0x0002

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x00002b4f

ub4 kcrbabno @504 0x0002c2fe

ub2 kcrbabof @508 0x0000

ub1 kcvcpetb[0] @512 0x06

ub1 kcvcpetb[1] @513 0x00

BBED> sum apply

Check value for File 1, Block 1:

current = 0xcb25, required = 0xcb25

这篇关于【故障处理】DG环境主库丢失归档情况下数据文件的恢复（4）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！

Java教程