Oracle 如何恢复ASM磁盘头

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

 

试想一下,磁盘组中有一个磁盘的头出现损坏;磁盘组被设置为外部冗余,就意味着一个磁盘无法访问,整个磁盘组将被卸除。那又怎样?这个磁盘具有良好的业务数据,其他磁盘也有很好的业务数据,而这里的问题是,若只有一个磁盘的头出现损坏,应不应该因为一个盘头重建整个数据库? 来吧!这就是oracle!总有解决方法的。这就是我在这篇文章中尝试做的,提出一些方法来备份ASM磁盘头,并在需要时恢复。

注:我还没有看到有关这方面的解决方法,小心操作。

我可以告诉你关于测试环境的更多详细信息,有一个磁盘组名为“DATA”:

SQL> select group_number, name, state, type from v$asm_diskgroup;

GROUP_NUMBER NAME                STATE       TYPE
———— ——————- ———– ——
       1     DATA                MOUNTED     EXTERN

注意看分配单位的大小;这个日期对于我们接下来的操作非常重要:

SQL> select allocation_unit_size from v$asm_diskgroup;

ALLOCATION_UNIT_SIZE

——————–

           1048576

磁盘组 DATA 使用两个磁盘:

SQL> select group_number, name, mount_status, header_status, state from v$asm_disk;

GROUP_NUMBER NAME                MOUNT_S HEADER_STATU STATE
———— ——————- ——- ———— ——–
       1     DATA_0001           CACHED  MEMBER       NORMAL
       1     DATA_0000           CACHED  MEMBER       NORMAL

检查一下使用 “kfed read”时磁盘头是否正常:

[grid@a1 dbs]$ kfed read /dev/oracleasm/disks/ASMDISK1
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                   298064398 ; 0x00c: 0x11c41a0e
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISKASMDISK1 ; 0x000: length=16
kfdhdb.driver.reserved[0]:   1145918273 ; 0x008: 0x444d5341
kfdhdb.driver.reserved[1]:    827020105 ; 0x00c: 0x314b5349
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               DATA_0000 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0000 ; 0x068: length=9

到目前为止,看起来一切都好。

现在我们要新建一个表,以检查元数据恢复后我们的数据是否不变。

SQL> create table dgomez(id number primary key, value varchar2(20));

Table created.

SQL> insert into dgomez values (1,’deiby’);

1 row created.

SQL> insert into dgomez values (2,’gomez’);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from dgomez.dgomez;

        ID VALUE
———- ——————–
         1 deiby
         2 gomez

2 rows selected.

完美。我们看到ASMDISK1的元数据很好,我们有个两行的表。是时候损坏ASM磁盘的头:

[grid@a1 dbs]$ dd if=/dev/zero of=/dev/oracleasm/disks/ASMDISK1 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000505259 seconds, 8.1 MB/s

我们就停在这里,因为这里有很多有趣的信息:

  • 根据Oracle文档,ASM磁盘头使用第一个AU的第一个块。所以我们的块大小为4096个字节。你还记得我们的AU大小吗,是的,就是1MB
  • 我们正在做什么呢?我们正在破坏ASM磁盘头。
  • Partnership Status Table (PST) 使用每个磁盘的第二个AU

我们破坏所有数据,只为了看清楚损坏。

oracle@a1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 15 12:52:21 2014

版权所有(c1982年,2013年,Oracle 版权所有

连接到:
Oracle数据库11g 企业版发布11.2.0.4.0- 64位生产

附带有分区,自动存储管理,OLAP,数据挖掘和真正应用测试选项。

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>

[grid@a1 dbs]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 15 11:33:49 2014

版权所有(c1982年,2013年,Oracle 版权所有

连接到:
Oracle数据库11g 企业版发布11.2.0.4.0- 64位生产

附带有自动存储管理选项。

SQL> alter diskgroup data dismount;

Diskgroup altered.

SQL> alter diskgroup data mount;
alter diskgroup data mount
*
位于第1行的错误:
ORA-15032: not all alterations performed
ORA-15017: diskgroup “DATA” cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATA”

SQL> exit

Oracle数据库11g断开连接 企业版发布11.2.0.4.0- 64位生产

附带有自动存储管理选项。

好的,很高兴看到我们的ASMDISK1受损。现在我们要恢复它。

[grid@a1 ~]$ kfed repair /dev/oracleasm/disks/ASMDISK1

[grid@a1 ~]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 15 17:54:13 2014

版权所有(c1982年,2013年,Oracle 版权所有

连接到:
Oracle数据库11g 企业版发布11.2.0.4.0- 64位生产

附带有自动存储管理选项。

SQL> alter diskgroup data mount;

更改磁盘组。

这个方法有用。Oracle怎样恢复磁盘头呢?我是说,我们没有对ASM磁盘头进行任何备份。在510号块中磁盘头有秘密备份。我们不讨论这个问题,因为它不是这篇文章的主要目的。点击以下链接,有更多详细信息:

http://laurent-leturgez.com/2012/11/12/how-asm-disk-header-block-repair-works/

SQL> select group_number, name, state, type from v$asm_diskgroup;

GROUP_NUMBER NAME                STATE    TYPE
———— ——————- ——– ——
       1     DATA                MOUNTED  EXTERN

SQL> select group_number, name, mount_status, header_status, state from v$asm_disk;

GROUP_NUMBER NAME                MOUNT_S HEADER_STATU STATE
———— —————————— ——- ———— ——–
       1 DATA_0001                CACHED  MEMBER     NORMAL
       1 DATA_0000                CACHED  MEMBER     NORMAL

到目前为止,我们已经从从510号块的秘密副本中恢复了盘头,但这篇文章的主要问题是,如果破坏了AUD =1Block= 0510号块,如何恢复磁盘头?有时,“KFED repair”不能修复盘头,几天前我还在努力找出错误的根本原因:

NOTE: starting rebalance of group 8/0xabe8381c (DATA_11) at power 11

WARNING: cache read  a corrupt block: group=8(DATA_11) dsk=1 blk=1 disk=1 (DATA_11_0001) incarn=2526603743 au=0 blk=1 count=1

Errors in file /oracle/app/oracle/diag/asm/+asm/+ASM/trace/+ASM_rbal_12239.trc:

ORA-15196: invalid ASM block header [kfc.c:26076] [endian_kfbh] [2147483649] [1] [0 != 1]

NOTE: a corrupted block from group DATA_11 was dumped to /oracle/app/oracle/diag/asm/+asm/+ASM/trace/+ASM_rbal_12239.trc

WARNING: cache read (retry) a corrupt block: group=8(DATA_11) dsk=1 blk=1 disk=1 (DATA_11_0001) incarn=2526603743 au=0 blk=1 count=1

Errors in file

正如你所看到的,ASM无法读取Disk=1名为DATA_11_0001的头,我用了“KFED修复也没用。Oracle support 也在努力找出根本原因,但是并没有成功。

事实:

  • ASM 磁盘头损坏
  • Kfed 修复不起作用

……确实,如果510号块中秘密副本不存在,我们没有任何备份,那就没有别的隐秘的事了,所以我们必须创建自己的备份以防有任何损坏。

方法1:

创建ASM磁盘元数据备份

[grid@a1 ~]$ kfed read /dev/oracleasm/disks/ASMDISK1  text=/home/grid/kfed.bk

损坏:

[grid@a1 ~]$ dd if=/dev/zero of=/dev/oracleasm/disks/ASMDISK1 bs=4096 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB) copied, 1.2939e-05 seconds, 317 MB/s

[grid@a1 ~]$

你能解释一下为什么只有4096个字节吗?是的。因为ASM磁盘头位于第一个AU的第一个块中,而块的大小是4096个字节。

SQL> alter diskgroup data mount;

alter diskgroup data mount

*

ERROR at line 1:

ORA-15032: not all alterations performed

ORA-15017: diskgroup “DATA” cannot be mounted

ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATA”

恢复备份:

[grid@a1 ~]$ kfed write /dev/oracleasm/disks/ASMDISK1 text=/home/grid/kfed.bk

调出磁盘组:

SQL> alter diskgroup data mount;

Diskgroup altered.

我们的对象是什么?

SQL> select * from dgomez.dgomez;

     ID VALUE

———- ——————–

      1 deiby

      2 gomez

SQL>

是的,这就是表

方法 2:

创建ASM磁盘元数据备份

[grid@a1 ~]$ dd if=/dev/oracleasm/disks/ASMDISK1 of=/home/grid/ddDisk1.out  bs=4096 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB) copied, 2.5064e-05 seconds, 163 MB/s

损坏:

[grid@a1 ~]$ dd if=/dev/zero of=/dev/oracleasm/disks/ASMDISK1 bs=4096 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB) copied, 2.0905e-05 seconds, 196 MB/s

SQL> alter diskgroup data mount;

alter diskgroup data mount

*

位于第1行的错误:

ORA-15032: not all alterations performed

ORA-15017: diskgroup “DATA” cannot be mounted

ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATA”

还原备份:

[grid@a1 ~]$ dd if=/home/grid/ddDisk1.out of=/dev/oracleasm/disks/ASMDISK1  bs=4096 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB) copied, 0.00030255 seconds, 13.5 MB/s

[grid@a1 ~]$

调出磁盘组:

SQL> alter diskgroup data mount;

Diskgroup altered.

我们的对象是什么?

SQL> select * from dgomez.dgomez;

     ID VALUE

———- ——————–

      1 deiby

      2 gomez

SQL>

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569