二十二、用BBED 分析ASM disk header dump
SQL> select file_id,file_name,AUTOEXTENSIBLE from dba_data_files order by 1;

FILE_ID FILE_NAME AUTOEXTENSIBLE
———- ———————————————————— ——————–
########## +DATA01/alex/datafile/system.256.734564895 YES
########## +DATA01/alex/datafile/undotbs1.258.734564897 YES
########## +DATA01/alex/datafile/sysaux.257.734564897 YES
########## +DATA01/alex/datafile/users.259.734564897 YES
########## +DATA01/alex/datafile/roger01.dbf NO

SQL> show user

我这里只有一个ASM 磁盘组 我们来看看sysaux.257.734564897 这个文件 其中257就是ASM 内部 file number
该file number对应 x$kffxp.number_kffxp

SQL> select disk_kffxp, au_kffxp, xnum_kffxp
2 from x$kffxp
3 where GROUP_KFFXP=1 and
4 NUMBER_KFFXP=257;

DISK_KFFXP AU_KFFXP XNUM_KFFXP
———- ———- ———-
0 533 0
0 534 1
0 535 2
0 536 3
0 537 4
0 538 5
0 539 6
0 540 7
0 541 8
0 542 9
0 543 10

………省略部分内容
0 1010 247
0 1011 248
0 1012 249
0 1013 250
0 593 2147483648

252 rows selected.

从上面我们可以看到 一共是252条信息 也就是说sysaux.257.734564897 这个数据文件一共分配了251个AU(每个AU是1M)
即使整个sysaux数据文件的大小应该是251m -1m=250m OK 那我们来看看该数据文件是不是250m呢?
SQL> select file_name,tablespace_name,bytes/1024/1024,blocks from dba_data_files order by file_id;

FILE_NAME TABLESPACE_NAME BYTES/1024/1024 BLOCKS
———————————————————— —————————— ————— ———-
+DATA01/alex/datafile/system.256.734564895 SYSTEM 480 61440
+DATA01/alex/datafile/undotbs1.258.734564897 UNDOTBS1 25 3200
+DATA01/alex/datafile/sysaux.257.734564897 SYSAUX 250 32000
+DATA01/alex/datafile/users.259.734564897 USERS 5 640
+DATA01/alex/datafile/roger01.dbf ROGER 50 6400

SQL>
大家可以从上面看到 确实是250M

SQL> select number_kffxp file#, disk_kffxp disk#, count(disk_kffxp) extents
2 from x$kffxp
3 where group_kffxp=1
4 and disk_kffxp <> 65534
5 group by number_kffxp, disk_kffxp;

FILE# DISK# EXTENTS
———- ———- ———-
1 0 2 —ASM file 1,ASM file directory
2 0 1 —ASM file 2,ASM disk directory
3 0 42 —ASM file 3,ASM ACD
4 0 2 —ASM file 4,ASM COD
5 0 1 —ASM file 5,ASM template directory
6 0 1 —ASM file 6,alias directory
256 0 482 —SYSTEM tablespace datafile
257 0 252 —SYSAUX tablespace datafile
258 0 26 —UNDOTBS1 tablespace datafile
259 0 6 —USERS tablespace datafile
260 0 8

FILE# DISK# EXTENTS
———- ———- ———-
261 0 56
262 0 56
263 0 56
264 0 21
265 0 1
266 0 51 —ROGER tablespace datafile

17 rows selected.

SQL>

########## 下面我们来研究ASM DISK header

这里我用dd 然后再使用bbed

[oracle@roger ~]$ dd if=/dev/sdb bs=4096 count=1 of=asm_header —首先用dd将ASM disk header备份出来
1+0 records in
1+0 records out
[oracle@roger ~]$
[oracle@roger ~]$ ls -ltr
total 20
-rw-r–r– 1 oracle dba 4096 Nov 9 20:12 dd_sdb_header
-rw-r–r– 1 oracle dba 6610 Nov 9 20:25 header.txt
-rw-r—– 1 oracle dba 3529 Nov 14 18:19 sqlnet.log
-rw-r–r– 1 oracle dba 4096 Nov 21 17:09 asm_header
[oracle@roger ~]$ pwd
/home/oracle

下面将dd备份出来的文件 加入到bbed的 listfile文件中 如下:
[oracle@roger lib]$ cat a.txt
1 /home/oracle/asm_header
[oracle@roger lib]$

[oracle@roger lib]$ ./bbed parfile=parfile.txt
Password:

BBED: Release 2.0.0.0.0 – Limited Production on Sun Nov 21 17:10:36 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

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

BBED> show all
FILE# 1
BLOCK# 1
OFFSET 0
DBA 0×00400001 (4194305 1,1)
FILENAME /home/oracle/asm_header
BIFILE bifile.bbd
LISTFILE a.txt
BLOCKSIZE 512
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 512
LOGFILE log.bbd
SPOOL Yes
BBED> map /v
File: /home/oracle/asm_header (1)
Block: 1 Dba:0×00400001
————————————————————
Undo Segment Header

struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18

struct ktect, 44 bytes @20
ub4 ktectspare @20
word ktecttsn @24
ub4 ktectobj @28
ub4 ktectnex @32
ub2 ktecttbe @36
ub4 ktectcex @40
ub4 ktectces @44
ub4 ktectcbk @48
struct ktectxid, 8 bytes @52
ub1 ktectlck @60

struct ktetb[1], 8 bytes @64
ub4 ktetbdba @64
ub4 ktetbnbk @68

struct ktuxc, 104 bytes @18776
struct ktuxcscn, 8 bytes @18776
struct ktuxcuba, 8 bytes @18784
sb2 ktuxcflg @18792
ub2 ktuxcseq @18794
sb2 ktuxcnfb @18796
ub4 ktuxcinc @18800
sb2 ktuxcchd @18804
sb2 ktuxcctl @18806
ub2 ktuxcmgc @18808
ub4 ktuxcopt @18816
struct ktuxcfbp[5], 60 bytes @18820

struct ktuxe[255], 10200 bytes @18880
ub4 ktuxexid @18880
ub4 ktuxebrb @18884
struct ktuxescn, 8 bytes @18888
sb4 ktuxesta @18896
ub1 ktuxecfl @18897
sb2 ktuxeuel @18898

ub4 tailchk @508

BBED> p kcbh –block header的信息 一共占了20byte
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0×01
ub1 frmt_kcbh @1 0×82
ub1 spare1_kcbh @2 0×01
ub1 spare2_kcbh @3 0×01
ub4 rdba_kcbh @4 0×00000000
ub4 bas_kcbh @8 0×80000000
ub2 wrp_kcbh @12 0x1d56
ub1 seq_kcbh @14 0×85
ub1 flg_kcbh @15 0×78 (NONE)
ub2 chkval_kcbh @16 0×0000
ub2 spare3_kcbh @18 0×0000

BBED> d /v count 4096
File: /home/oracle/asm_header (1)
Block: 1 Offsets: 0 to 511 Dba:0×00400001
——————————————————-
01820101 00000000 00000080 561d8578 l …………V..x
00000000 00000000 00000000 00000000 l …………….
4f52434c 4449534b 00000000 00000000 l ORCLDISK……..
00000000 00000000 00000000 00000000 l …………….
0000100a 00000103 44415441 30315f30 l ……..DATA01_0
30303000 00000000 00000000 00000000 l 000………….
00000000 00000000 44415441 30310000 l ……..DATA01..
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 44415441 30315f30 l ……..DATA01_0
30303000 00000000 00000000 00000000 l 000………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 15adf601 00447ca5 l ………..D|?
abaef601 00ac21ad 00020010 00001000 l ?.??…….
80bc0100 00140000 02000000 01000000 l .?………….
02000000 02000000 00000000 00000000 l …………….
0000100a 15adf601 00187ba5 00000000 l …..…{?…
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….
00000000 00000000 00000000 00000000 l …………….

<16 bytes per line>

下面我们来对上面的dump信息进行解释:
1)第1个byte 01 –这里是对应的endian_kfbh 01即使1 表示的是Little Endian 相反,0的话即使表示BIG endian
2)第2个byte 82 –这里对应kfbh.hard
3)第3个byte 01 –这里对应kfbh.type
4)第4个byte 01 –这里对应的是datfmt_kfbh
5)第5~8个byte 00 00 00 00 —这里对应的是kfbh.block.blk
6)第9~12个byte 00 00 00 08 —这里对应的是kfbh.block.obj
7)第13~16个byte 561d8578 —这里对应的是kfbh.check (可以对比下面的kfed结果)
8)第17~20个byte 00000000 —这里对应的是kfbh.fcn.base
9)第21~23个byte 00000000 —这里对应的是kfbh.fcn.wrap
10)第24~27个byte 00000000 —这里对应的是kfbh.spare1
11)第28~32个byte 00000000 —这里对应的是kfbh.spare2
12)第33~40个byte 4f52434c 4449534b —这里对应的是kfdhdb.driver.provstr –从上面的dump信息可以看出具体的值
13)第41~64个byte 00 00 00 00 —这里对应的是kfdhdb.driver.reserved[0] ~~ kfdhdb.driver.reserved[5]
14)第65~68个byte 0000100a —这里对应的是kfdhdb.compat 即使我们的oracle版本号
15)第69~70个byte 0000 —这里对应的是kfdhdb.dsknum 即使disk numer 取值范围 0~65335
16)第71个byte 01 —这里对应的是kfdhdb.grptyp 即磁盘组的冗余方式 01 表示EXTERNAL冗余

下面对该值的属性做一下补充:
KFDGTP_INVALID ((kfdgtp)0) — Illegal value
KFDGTP_EXTERNAL ((kfdgtp)1) — External redundancy
KFDGTP_NORMAL ((kfdgtp)2) — Normal redundancy
KFDGTP_HIGH ((kfdgtp)3) — High redundancy

17)第72个byte 03 —这里对应是kfdhdb.hdrsts 即disk group的状态 03表示正常(这里非常重要)

下面对改值的熟悉做一下补充:

KFDHDR_INVALID ((kfdhdr)0) — Illegal value
KFDHDR_UNKNOWN ((kfdhdr)1) — Disk header block unreadable
KFDHDR_CANDIDATE ((kfdhdr)2) — No OSM or OS disk header found
KFDHDR_MEMBER ((kfdhdr)3) — Normal member of the group —03 正常状态
KFDHDR_FORMER ((kfdhdr)4) — Disk dropped cleanly from group
KFDHDR_CONFLICT ((kfdhdr)5) — Header conflicts
KFDHDR_INCOMPAT ((kfdhdr)6) — Written by incompatible software
KFDHDR_PROVISIONED ((kfdhdr)7) — Disk was prepared beforehand

18)第73~104个byte 44415441 到00000000 32个byte —这里对应的是kfdhdb.dskname 即磁盘名称 我们这里的DATA01_0000
19) 第105~~136个byte 44415441 到00000000 32个byte —这里对应的是kfdhdb.grpname 即是磁盘组名称 DATA01
20)第137~ 168个byte 也是44415441开始 32个byte —这里对应的是kfdhdb.fgname 即failgroup name
21)第169~184 个byte 一共16个byte —这里对应的是kfdhdb.capname 即是Capacitygroup name 当然我这里没有使用
22)第185~188个byte 一共4个byte —这里对应的是kfdhdb.crestmp.hi 即Creation timestamp high
23)第189~192个byte 一共4个byte —这里对应的是kfdhdb.crestmp.lo 即Creation timestamp low
24)第193~196个byte 一共4个byte —这里对应的是kfdhdb.mntstmp.hi
25)第197~200个byte 一共4个byte —这里对应的是kfdhdb.mntstmp.lo
26)第201~202 一共2个byte —这里对应的是kfdhdb.secsize 即physical sector size of the disk
27)第203~204 一共2个byte —这里对应的是fdhdb.blksize 即metadata blocksize asm block大小
28)第205~208 一共4个byte —这里对应的是kfdhdb.ausize 即AU 的大小1048576 即是1m
29)第209~212 一共4个byte —这里对应的是kfdhdb.mfact 即Stride between physical addresses of allocation units
30)第213~216 一共4个byte —这里对应的是kfdhdb.dsksize 即0×00001400 转换为10进制后为5120 即5120个分配units =磁盘组大小

补充:

kfdhdb.ausize * dsksize_kfdhdb = disk size

即是 1m x 5120 =5120m (注意这个大小是整个磁盘组的大小)

31)第217~220 一共4个byte —这里对应的是kfdhdb.pmcnt 这里该值是2 即 Number of physically addressed allocation units
32)第221~224 一共4个byte —这里对应的是kfdhdb.fstlocn 即First FreeSpace table block number used to find freespace。
33)第225~228 一共4个byte —这里对应的是kfdhdb.altlocn 即First Alocation table block numer used to find allocated space
34)第229~232 一共4个byte —这里对应的是kfdhdb.f1b1locn 即File Directory block 1 Allocation Unit number. Beginging for file directory
即是第一个file directory 通常这里是2

35)第241~244 一共4个byte —这里对应的是kfdhdb.dbcompat 转换以为即为我们的数据库版本
36)第245~248 一共4个byte —这里对应的是kfdhdb.grpstmp.hi

我们这里的值是 HOUR=0×15 DAYS=0×8 MNTH=0xb YEAR=0x7da
0x7da –>2010
0xb –>11
0×8 –>8
0×15 –>21 即2010/11/08 21 这里只是精确到小时

37)第249~252 一共4个byte —这里对应的是kfdhdb.grpstmp.lo
我们这里的值是 USEC=0×0 MSEC=0x2c6 SECS=0×17 MINS=0×29
MINS=0×29 –>41 分钟
SECS=0×17 –>23 秒
MSEC=0x2c6 –>710 微秒即0.7s
USEC=0×0 –>0

下面是kfed asm disk header的信息,如下:

kfbh.endian: 1 ; 0×000: 0×01
kfbh.hard: 130 ; 0×001: 0×82
kfbh.type: 1 ; 0×002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0×003: 0×01
kfbh.block.blk: 0 ; 0×004: T=0 NUMB=0×0
kfbh.block.obj: 2147483648 ; 0×008: TYPE=0×8 NUMB=0×0
kfbh.check: 2021989718 ; 0x00c: 0x78851d56
kfbh.fcn.base: 0 ; 0×010: 0×00000000
kfbh.fcn.wrap: 0 ; 0×014: 0×00000000
kfbh.spare1: 0 ; 0×018: 0×00000000
kfbh.spare2: 0 ; 0x01c: 0×00000000
kfdhdb.driver.provstr: ORCLDISK ; 0×000: length=8
kfdhdb.driver.reserved[0]: 0 ; 0×008: 0×00000000
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0×00000000
kfdhdb.driver.reserved[2]: 0 ; 0×010: 0×00000000
kfdhdb.driver.reserved[3]: 0 ; 0×014: 0×00000000
kfdhdb.driver.reserved[4]: 0 ; 0×018: 0×00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0×00000000
kfdhdb.compat: 168820736 ; 0×020: 0x0a100000
kfdhdb.dsknum: 0 ; 0×024: 0×0000
kfdhdb.grptyp: 1 ; 0×026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0×027: KFDHDR_MEMBER
kfdhdb.dskname: DATA01_0000 ; 0×028: length=11
kfdhdb.grpname: DATA01 ; 0×048: length=6
kfdhdb.fgname: DATA01_0000 ; 0×068: length=11
kfdhdb.capname: ; 0×088: length=0
kfdhdb.crestmp.hi: 32943381 ; 0x0a8: HOUR=0×15 DAYS=0×8 MNTH=0xb YEAR=0x7da
kfdhdb.crestmp.lo: 2776384512 ; 0x0ac: USEC=0×0 MSEC=0×311 SECS=0×17 MINS=0×29
kfdhdb.mntstmp.hi: 32943787 ; 0x0b0: HOUR=0xb DAYS=0×15 MNTH=0xb YEAR=0x7da
kfdhdb.mntstmp.lo: 2904665088 ; 0x0b4: USEC=0×0 MSEC=0x6b SECS=0×12 MINS=0x2b
kfdhdb.secsize: 512 ; 0x0b8: 0×0200
kfdhdb.blksize: 4096 ; 0x0ba: 0×1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0×00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 5120 ; 0x0c4: 0×00001400
kfdhdb.pmcnt: 2 ; 0x0c8: 0×00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0×00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0×00000002
kfdhdb.f1b1locn: 2 ; 0x0d4: 0×00000002
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0×0000
kfdhdb.redomirrors[1]: 0 ; 0x0da: 0×0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0×0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0×0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32943381 ; 0x0e4: HOUR=0×15 DAYS=0×8 MNTH=0xb YEAR=0x7da
kfdhdb.grpstmp.lo: 2776307712 ; 0x0e8: USEC=0×0 MSEC=0x2c6 SECS=0×17 MINS=0×29
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0×00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0×00000000
kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0×00000000
kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0×00000000
kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0×00000000
kfdhdb.ub4spare[5]: 0 ; 0×100: 0×00000000
kfdhdb.ub4spare[6]: 0 ; 0×104: 0×00000000
kfdhdb.ub4spare[7]: 0 ; 0×108: 0×00000000
kfdhdb.ub4spare[8]: 0 ; 0x10c: 0×00000000
kfdhdb.ub4spare[9]: 0 ; 0×110: 0×00000000
kfdhdb.ub4spare[10]: 0 ; 0×114: 0×00000000
kfdhdb.ub4spare[11]: 0 ; 0×118: 0×00000000
kfdhdb.ub4spare[12]: 0 ; 0x11c: 0×00000000
kfdhdb.ub4spare[13]: 0 ; 0×120: 0×00000000
kfdhdb.ub4spare[14]: 0 ; 0×124: 0×00000000
kfdhdb.ub4spare[15]: 0 ; 0×128: 0×00000000
kfdhdb.ub4spare[16]: 0 ; 0x12c: 0×00000000
kfdhdb.ub4spare[17]: 0 ; 0×130: 0×00000000
kfdhdb.ub4spare[18]: 0 ; 0×134: 0×00000000
kfdhdb.ub4spare[19]: 0 ; 0×138: 0×00000000
kfdhdb.ub4spare[20]: 0 ; 0x13c: 0×00000000
kfdhdb.ub4spare[21]: 0 ; 0×140: 0×00000000
kfdhdb.ub4spare[22]: 0 ; 0×144: 0×00000000
kfdhdb.ub4spare[23]: 0 ; 0×148: 0×00000000
kfdhdb.ub4spare[24]: 0 ; 0x14c: 0×00000000
kfdhdb.ub4spare[25]: 0 ; 0×150: 0×00000000
kfdhdb.ub4spare[26]: 0 ; 0×154: 0×00000000
kfdhdb.ub4spare[27]: 0 ; 0×158: 0×00000000
kfdhdb.ub4spare[28]: 0 ; 0x15c: 0×00000000
kfdhdb.ub4spare[29]: 0 ; 0×160: 0×00000000
kfdhdb.ub4spare[30]: 0 ; 0×164: 0×00000000
kfdhdb.ub4spare[31]: 0 ; 0×168: 0×00000000
kfdhdb.ub4spare[32]: 0 ; 0x16c: 0×00000000
kfdhdb.ub4spare[33]: 0 ; 0×170: 0×00000000
kfdhdb.ub4spare[34]: 0 ; 0×174: 0×00000000
kfdhdb.ub4spare[35]: 0 ; 0×178: 0×00000000
kfdhdb.ub4spare[36]: 0 ; 0x17c: 0×00000000
kfdhdb.ub4spare[37]: 0 ; 0×180: 0×00000000
kfdhdb.ub4spare[38]: 0 ; 0×184: 0×00000000
kfdhdb.ub4spare[39]: 0 ; 0×188: 0×00000000
kfdhdb.ub4spare[40]: 0 ; 0x18c: 0×00000000
kfdhdb.ub4spare[41]: 0 ; 0×190: 0×00000000
kfdhdb.ub4spare[42]: 0 ; 0×194: 0×00000000
kfdhdb.ub4spare[43]: 0 ; 0×198: 0×00000000
kfdhdb.ub4spare[44]: 0 ; 0x19c: 0×00000000
kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0×00000000
kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0×00000000
kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0×00000000
kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0×00000000
kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0×00000000
kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0×00000000
kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0×00000000
kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0×00000000
kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0×00000000
kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0×00000000
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0×00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0×00000000
kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0×00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0×00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0×00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0×0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0×0000

既然我们知道了asm disk header的每个byte的意思,那么如果是header出现问题导致asm 磁盘组无法mount之类的问题,处理起来就非常简单了。

Trackback

no comment untill now

Add your comment now

切换到手机版