首页 > 其他分享> > 【故障处理】DG环境主库丢失归档情况下数据文件的恢复（5）

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

2021-04-18 16:54:13 作者：互联网

1 BLOG文档结构图

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

3、 修复数据文件头的序列号

要想跳过归档还需要数据文件头块的rba。它由seq#、log block#、偏移量(固定为16)组成，决定了数据文件从哪个归档日志的哪个位置开始应用归档。Rba位于数据文件头块偏移量500处开始连续的12个字节，有关RBA的理论知识参考：http://blog.itpub.net/26736162/viewspace-2079337/

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

File: /tmp/a.dbf (1)

Block: 1 Offsets: 500 to 563 Dba:0x00400001

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

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

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

<16 bytes per line>

BBED> modify /x 00003275 dba 1,1 offset 500

File: /tmp/a.dbf (1)

Block: 1 Offsets: 500 to 563 Dba:0x00400001

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

00003275 0002c2fe 00000010 06000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply

Check value for File 1, Block 1:

current = 0xd21f, required = 0xd21f

BBED> modify /x 00000002 dba 1,1 offset 504

File: /tmp/a.dbf (1)

Block: 1 Offsets: 504 to 567 Dba:0x00400001

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

00000002 00000010 06000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> sum apply

Check value for File 1, Block 1:

current = 0x10e1, required = 0x10e1

BBED> modify /x 00000010 dba 1,1 offset 508

File: /tmp/a.dbf (1)

Block: 1 Offsets: 508 to 571 Dba:0x00400001

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

00000010 06000000 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 1, Block 1:

current = 0xd21f, required = 0xd21f

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

File: /tmp/a.dbf (1)

Block: 1 Offsets: 500 to 563 Dba:0x00400001

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

00003275 00000002 00000010 06000000 l ..2u............

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

<16 bytes per line>

BBED> p kcvfhckp

struct kcvfhckp, 160 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas @484 0xab647c08

ub2 kscnwrp @488 0x0003

ub4 kcvcptim @492 0x342e3478

ub2 kcvcpthr @496 0x0002

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x00003275

ub4 kcrbabno @504 0x00000002

ub2 kcrbabof @508 0x0000

ub1 kcvcpetb[0] @512 0x06

ub1 kcvcpetb[1] @513 0x00

ub1 kcvcpetb[2] @514 0x00

ub1 kcvcpetb[3] @515 0x00

修复完毕，BBED的任务已经完成。

下边将文件从文件系统拷贝到ASM中：

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

-rw-r----- 1 oracle dba 104865792 Sep 20 17:39 /tmp/a.dbf

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

[ZFLHRSDB1:root]:/>su - grid

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

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

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

ASMCMD>

[ZFLHRSDB1:root]:/>su - oracle

[ZFLHRSDB1:oracle]:/oracle>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Tue Sep 20 17:47:21 2016

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Data Mining and Real Application Testing options

SYS@oraLHRD1> alter database rename file '+DATA1/oralhrs/datafile/tbs101.262.923076161' TO '+DATA1/oralhrs/datafile/a.dbf';

Database altered.

SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status FROM v$datafile_header a WHERE A.FILE# IN (1,2,64);

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

====>>>>>从截图可以看出虽然是OFFLINE状态，但是CHECKPOINT_CHANGE#已经和其它文件是一致的了。

SYS@oraLHRD1> COL CHANGE# FOR 999999999999999

SYS@oraLHRD1> select file#,online_status,change#,ERROR from v$recover_file;

FILE# ONLINE_ CHANGE# ERROR

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

64 OFFLINE 15760391176

SYS@oraLHRD1> recover datafile 64;

Media recovery complete.====>>>>>恢复操作成功完成。

SYS@oraLHRD1> alter database datafile 64 online;

Database altered.====>>>>>数据文件成功ONLINE了。

SYS@oraLHRD1>

SYS@oraLHRD1> select file#,online_status,change#,ERROR from v$recover_file;

no rows selected====>>>>>没有需要恢复的文件了

SYS@oraLHRD1> COL CHECKPOINT_CHANGE# FOR 999999999999999

SYS@oraLHRD1> SELECT a.FILE#,a.RECOVER,a.CHECKPOINT_CHANGE#,status FROM v$datafile_header a WHERE A.FILE# IN (1,2,64);

FILE# REC CHECKPOINT_CHANGE# STATUS

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

1 NO 15760391176 ONLINE

2 NO 15760391176 ONLINE

64 NO 15760480489 ONLINE

此时再次查询表空间的占用情况，已经可以看到了TBS101的大小了：

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

接下来创建一个表，看看表空间是否正常：

SYS@oraLHRD1> CREATE TABLE T_TEST_LHR TABLESPACE TBS101 NOLOGGING AS SELECT * FROM DBA_OBJECTS;

Table created.

SYS@oraLHRD1> insert into t_test select * from T_TEST_LHR;

198881 rows created.

SYS@oraLHRD1> commit;

Commit complete.

SYS@oraLHRD1> ALTER SYSTEM CHECKPOINT;

System altered.

SYS@oraLHRD1>

再次查看表空间大小：

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

表空间占用从原来的11M到现在的63M，正常了。

标签：主库,tmp,BBED,数据文件,00000000,DG,oraLHRD1,SYS,dbf
来源： https://blog.51cto.com/lhrbest/2715814