今天在 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/