Oracle asm kfed 工具的使用和修复例子

Oracle asm kfed 工具的使用

今天在 pub 上看到有人的 asm disk header 出现了问题，然后他就拿 kfed 去 dump 出 disk header 的内容。那什么是 kfed 呢？

Kfed 是 oracle 10gr2 后自带的一个工具，但需要手工编译才能使用。

cd $ORACLE_HOME/rdbms/lib

make -f ins_rdbms.mk ikfed

此时$ORACLE_HOME/bin目录中将会产生kfed程序。

使用kfed的语法是：kfed read *devicename* text=*filename*

假设我们要读取/dev/raw/raw1的文件头，那么使用下面的语句

kfed read /dev/raw/raw1 text=raw1.out  （这只是kfed 的比较常用的用法，其它用法可使用 kfed –h 命令）

这样raw1的文件头信息将会被dump到raw1.out文件中，大家有兴趣可以去看一下文件内容，基本上通过名字和值还是能猜测出都是些什么内容的，包括了这个ASM Disk创建时间是什么，每个block多大，Disk名字是什么，属于哪个Disk Group，Header Status是怎么样的。虽然大部分内容都可以从ASM实例的数据字典中获得，但是在我们碰到ASM磁盘故障的时候，kfed提供的信息往往更容易让我们判断问题点。

一般情况下，对于现在我的水平而言，通过 kfed 判断问题就是 对比每个 asm disk 的 header 的内容，通过对比发现问题。

In the failing node, if the disk is not the same, you will get different output or the operation will fail.

KFED-00303: unable to open file ''

 

以下是 kfed 的 范例和 kfed 的一些解释：

 

  example:

 

   % kfed read /dev/raw/raw1

  

   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: T=0 NUMB=0x0

   kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0

   kfbh.check:                  2932902794 ; 0x00c: 0xaed08b8a

   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:         ORCLDISK ; 0x000: length=8

   kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000

   kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000

   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:              ASM01_0000 ; 0x028: length=10

   kfdhdb.grpname:                   ASM01 ; 0x048: length=5

   kfdhdb.fgname:               ASM01_0000 ; 0x068: length=10

   kfdhdb.capname:                         ; 0x088: length=0

   kfdhdb.crestmp.hi:             32837774 ; 0x0a8: HOUR=0xe DAYS=0x4 MNTH=0x4 YEAR=0x7d4

   kfdhdb.crestmp.lo:           1555722240 ; 0x0ac: USEC=0x0 MSEC=0x29c SECS=0xb MINS=0x17

   kfdhdb.mntstmp.hi:             32837774 ; 0x0b0: HOUR=0xe DAYS=0x4 MNTH=0x4 YEAR=0x7d4

   kfdhdb.mntstmp.lo:           1563864064 ; 0x0b4: USEC=0x0 MSEC=0x1ab SECS=0x13 MINS=0x17

   kfdhdb.secsize:                     512 ; 0x0b8: 0x0200

   kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000

   kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000

   kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80

   kfdhdb.dsksize:                    9075 ; 0x0c4: 0x00002373

   kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002

   kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001

   kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002

   kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002

   kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000

   kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000

   kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000

   kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000

   kfdhdb.ub4spare[0]:                   0 ; 0x0e0: 0x00000000

   ...

   kfdhdb.ub4spare[60]:                  0 ; 0x1d0: 0x00000000

   kfdhdb.acdb.aba.seq:                  0 ; 0x1d4: 0x00000000

   kfdhdb.acdb.aba.blk:                  0 ; 0x1d8: 0x00000000

   kfdhdb.acdb.ents:                     0 ; 0x1dc: 0x0000

   kfdhdb.acdb.ub2spare:                 0 ; 0x1de: 0x0000

 

-------- kfed 的一些 名词的解释

  Breakdown:

 

   kfbh.endian

     kf3.h   /* endianness of writer */

       Little endian = 1

       Big endian = 0

 

   kfbh.hard  

     kf3.h   /* H.A.R.D. magic # and block size */

 

  kfbh.type

    kf3.h    /* metadata block type               */

 

  kfbh.datfmt

    kf3.h   /* metadata block data format        */

 

  kfbh.block

    kf3.h   /* block location of this block      */               

      blk -- Disk header should have T=0 and NUMB=0x0

      obj -- Disk header should have TYPE=0x8 NUMB=

    blk and obj values are derived from a series of macros in kf3.h.  See

 

    "KFBL Macros" in kf3.h for more information.

 

  kfbh.check

    kf3.h   /* check value to verify consistency */

 

  kfbh.fcn

    kf3.h   /* change number of last change      */-

 

  kfdhdb.driver

    kf3.h   /* OSMLIB driver reserved block  */

       If no driver is defined "ORCLDISK" is used.

 

  kfdhdb.compat

    kf3.h   /* Comaptible software version   */

      example: 0x0a100000

      You get:    

          a=10 1=1 so 10.1.0.0.0

 

  kfdhdb.dsknum

    kf3.h   /* OSM disk number               *

      This is the disk number.  The first disk being "0".  There can be up to

      ub2 disks in a diskgroup.  This allows for 65336 disks 0 through 65335.

 

  kfdhdb.grptyp

    kf3.h   /* Disk group type               */

 

  kfdhdb.hdrsts

    kf3.h   /* Disk header status            */

      This is what is used to determine if a disk is available or not to

      the diskgroup.  0x03 is the correct value for a valid status.

 

  kfdhdb.dskname   /* OSM disk name       */

  kfdhdb.grpname   /* OSM disk group name */

  kfdhdb.fgname    /* Failure group name  */

  kfdhdb.capname   /* Capacity grp, unused*/

    kf3.h

   

  kfdhdb.crestmp   /* Creation timestamp            */

  kfdhdb.mntstmp   /* Mount timestamp               */

    kf3.h To derive the hi and low time`from an unformated dump use the

    "KFTS Macros" in kf3.h.

 

  kfdhdb.secsize

    kf3.h   /* Disk sector size (bytes)      */

      This is the physical sector size of the disk in bytes. All I/O's to the

      disk are described in physical sectors. This must be a power of 2. An

      ideal value would be 4096, but most disks are formatted with 512 byte

      sectors. (from asmlib.h)

 

  kfdhdb.blksize

    kf3.h   /* Metadata block (bytes)        */

 

  kfdhdb.ausize

    kf3.h   /* Allocation Unit (bytes)       */

   

  kfdhdb.mfact

    kf3.h   /* Stride between phys addr AUs  */

   

  kfdhdb.dsksize

    kf3.h   /* Disk size in AUs              */

      Mulitply by AUs to get actual size of disk when added.

     

  kfdhdb.pmcnt

    kf3.h   /* Permanent phys addressed AUs  */

      Number of physically addressed allocation units.

     

  kfdhdb.fstlocn

    kf3.h   /* First FreeSpace table blk num */

      Used to find freespace.

     

  kfdhdb.altlocn

    kf3.h   /* First Alocation table blk num */

      Used to find alocated space.

     

  kfdhdb.f1b1locn

    kf3.h   /* File Directory blk 1 AU num   */

      Beginging for file directory.

 

另外，对于 kfed 修复 asm disk header 的案例，有一些例子，大概是这样：

假设 asm diskgoup 中有两个 disk ，disk0 和 disk1

1、dd 命令情况 disk1 的 header

dd if=/dev/zero f=/oracle/oradata/asmdisk04 bs=4096 count=1

2、启动磁盘组，报错

3、使用 kfed read 命令，备份 disk0 的header，然后手工编辑 备份文件，改成 disk1 相关的内容，最后使用 kfed merge 还原 disk1 的  header

kfed read /oracle/oradata/asmdisk07 > asmdisk04.new.txt

----手工修改 asmdisk04.new.txt 的相关内容

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

　　kfed merge /oracle/oradata/asmdisk04 text=asmdisk04.new.txt

 

再给出一些 asm 中 错误例子（可以使用 kfed 工具辅助查看）

http://www.taobaodba.com/html/68_using_kfed_dump_asm_disk_header.html#more-68

http://askdba.org/weblog/2008/05/ora-15063-asm-discovered-insufficient-amount-of-disks-2/

 

主要参考网址：

http://blog.chinaunix.net/u1/59967/showart_493416.html

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14730395/viewspace-682853/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14730395/viewspace-682853/