Coding TricksOracle uses BBED to view ASM Disk Header content
RAC ASM'S HIGH ENCAPSULATION MAKES IT DIFFICULT TO KNOW HOW TO SPY ON ITS INTERIOR. ASMS ARE OFTEN DIFFICULT TO DEAL WITH IF THEY HAVE PROBLEMS. EVEN WITH A FULL RMAN BACKUP, RECOVERY CAN TAKE A LONG TIME.
The most vulnerable of ASMs is ASM disk header. If the disk header logic is corrupted, i.e. corrupt, the entire disk group will not be able to mount, and database, which relies on ASM instances, will not be able to startup.
So what information is stored in the asm disk header? This can be viewed using the KFED command or the BBED command.
Roger's classmates organized the article to view the disk header using BBED, so this test followed Roger's lab steps.
the link to the original text is as follows:
http://ms.itpub.net/viewthread.php?tid=1370753
I. KFOD viewes the contents of the disk header
Using KFED to view, we've organized a blog, specifically for reference:
Oracle KFED and KFOD tool descriptions
http://www.cndba.cn/Dave/article/936
here's a direct intercept of the disk header:
[[email protected] ~]$ kfed read/dev/mapper/datap1
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=0x8NUMB=0x0
kfbh.check: 1508168608 ; 0x00c:0x59e4d3a0
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: ORCLDISKDATA ; 0x000: length=12
--> the name of the disk volume
kfdhdb.driver.reserved[0]: 1096040772 ; 0x008: 0x41544144
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
--> ThisindicatesRedundancy for Group.Check TYPE in query output.
kfdhdb.hdrsts: 3 ; 0x027:KFDHDR_MEMBER
--> This indicatesDiskHeader status. Here it indicates it is member of Group.
kfdhdb.dskname: DATA ; 0x028: length=4
--> This indicatesDiskName
kfdhdb.grpname: DATA ; 0x048: length=4
--> This indicatestheGroup Name for the disk.
kfdhdb.fgname: DATA ; 0x068: length=4
--> This indicatestheFailure Group Name.
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32952076 ; 0x0a8: HOUR=0xcDAYS=0x18 MNTH=0x3 YEAR=0x7db
kfdhdb.crestmp.lo: 3374491648 ; 0x0ac: USEC=0x0MSEC=0xaa SECS=0x12 MINS=0x32
kfdhdb.mntstmp.hi: 32955120 ; 0x0b0: HOUR=0x10DAYS=0x17 MNTH=0x6 YEAR=0x7db
kfdhdb.mntstmp.lo: 3440417792 ; 0x0b4: USEC=0x0MSEC=0x27 SECS=0x11 MINS=0x33
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 11993 ; 0x0c4: 0x00002ed9
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.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32952076 ; 0x0e4: HOUR=0xcDAYS=0x18 MNTH=0x3 YEAR=0x7db
kfdhdb.grpstmp.lo: 3374396416 ; 0x0e8: USEC=0x0MSEC=0x4d SECS=0x12 MINS=0x32
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000
......
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[57]: 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
II. View diskheader using BBED
THE USE OF BBED NEEDS TO BE COMPILED FIRST, THIS REFERENCE:
http://www.cndba.cn/Dave/article/1466
Five practical examples of Oracle bbed
http://www.cndba.cn/Dave/article/136
2.1 configure bed
[[email protected] u01]$ cat bbed.par
blocksize=8192
listfile=/u01/filelist.txt
mode=edit
[[email protected] u01]$
2.2 Export diskheader with the DD command
[email protected](rac2)> select path fromv$asm_disk;
PATH
--------------------------------------------------------------------------------
/dev/mapper/datap1
/dev/mapper/frap1
[[email protected] u01]$ ddif=/dev/mapper/datap1 of=/u01/asm_disk_header bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000297071seconds, 13.8 MB/s
[[email protected] u01]$ pwd
/u01
[[email protected] u01]$ ll asm_disk_header
-rw-r--r-- 1 oracle oinstall 4096 Sep 1 10:48 asm_disk_header
[[email protected] u01]$
2.3 add the exported disk header to the filelist of the bed
[[email protected] u01]$ cat filelist.txt
1 /u01/asm_disk_header
2.4 start bbed
[[email protected] lib]$ bbedparfile=/u01/bbed.par
Password:
BBED: Release 2.0.0.0.0 - LimitedProduction on Thu Sep 1 10:53:50 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
************* !!! For Oracle Internal Useonly !!! ***************
BBED> show all
FILE# 1
BLOCK# 1
-- here's file:1, block 1
OFFSET 0
DBA 0x00400001(4194305 1,1)
FILENAME /u01/asm_disk_header
BIFILE bifile.bbd
LISTFILE /u01/filelist.txt
BLOCKSIZE 512
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 512
LOGFILE log.bbd
SPOOL No
BBED> map /v dba 1,1
--see the details in block1
File: /u01/asm_disk_header (1)
Block: 1 Dba:0x00400001
------------------------------------------------------------
UndoSegment Header
struct kcbh, 20 bytes @0
the structure of the --kcbh takes up 20 bytes, which indicates the offset of the information in the block, i.e. the offset value
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
ub4tailchk @508
view the specific values in the kcbh structure
BBED> print kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x01
ub1 frmt_kcbh @1 0x82
ub1 spare1_kcbh @2 0x01
ub1 spare2_kcbh @3 0x01
ub4 rdba_kcbh @4 0x00000000
ub4 bas_kcbh @8 0x80000000
ub2 wrp_kcbh @12 0xd3a0
ub1 seq_kcbh @14 0xe4
ub1 flg_kcbh @15 0x59 (KCBHFNEW)
ub2 chkval_kcbh @16 0x0000
ub2 spare3_kcbh @18 0x0000
the same means offset, and the last column is the specific value.
dump this block, see the specifics:
BBED> dump /v dba 1,1 offset 0 count4096
File: /u01/asm_disk_header (1)
Block: 1 Offsets: 0 to 511 Dba:0x00400001
-------------------------------------------------------
01820101 00000000 00000080 a0d3e459 l............ ÓäY
00000000 00000000 00000000 00000000 l................
4f52434c4449534b 44415441 00000000 l ORCLDISKDATA....
00000000 00000000 00000000 00000000 l................
0000100a 00000103 44415441 00000000 l........ DATA....
00000000 00000000 00000000 00000000 l................
00000000 00000000 44415441 00000000 l........ DATA....
00000000 00000000 00000000 00000000 l................
00000000 00000000 44415441 00000000 l........ DATA....
00000000 00000000 00000000 00000000 l................
00000000 00000000 00000000 00000000 l................
00000000 00000000 00000000 00000000 l................
00000000 00000000 0ccff601 00a822c9 l......... Ïö.. ¨"É
f0daf601 009c10cd 00020010 00001000 lðÚö.... Í........
80bc0100 d92e0000 02000000 01000000 l.¼.. Ù...........
02000000 02000000 00000000 00000000 l................
0000100a 0ccff601 003421c9 00000000 l..... Ïö.. 4! É....
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>
BBED>
make a description of the bytes here:
Block: 1 Offsets: 0 to 511 Dba:0x00400001
-------------------------------------------------------
01820101 00000000 00000080 a0d3e459 l............ ÓäY
here each line of 16 themselves, that is, each block of 4 bytes, such as: 01820101, this piece is composed of 01, 82, 01 and 01 of the four byte.
2.5 explain the durmp information above
This section directly cites the achievements of Roger's classmates. Thanks to Roger for his hard work.
1) The first byte 01 -- here is the corresponding endian_kfbh 01 even if 1 means
Little Endian instead, 0 means BIGendian 2) 2nd byte 82 -- here is the third byte 01 for
kfbh.hard 3) -- here is the 4th byte 01 for kfbh.type
4) -- here is the datfmt_kfbh
5th byte 01) 5th to 8th byte 00 00 00000 --- here corresponds to kfbh.block.blk
6) 9th to 12th byte 00 00 0008 --- here corresponds to kfbh.block.obj
7) 13th to 16byte 561d8578 --- This corresponds to kfbh.check
8) 17th to 20th byte0000000000000 --- here corresponds to
kfbh.fcn.base 9) 21st to 23rd byte 0000000000000 --- --- here is kfbh.fcn.wrap
10) 24th to 27th byte 00000000000--- here is kfbh.spare1
11) 28th to 3rd 2 byte 0000000000 --- corresponds to kfbh.spare2
12) 33rd to
40th byte 4f52434c 4449534b --- corresponds here to kfdhdb.driver.provstr -- the specific value can be seen from the dump information above 13) 41 to 64 byte 00 00 00 00 --- Here is the correspondence is kfdhdb.driver.reserved (
s.kfdhdb.driver.reserved s.5) 65-68 byte 0000100a --- here corresponds to kfdhdb.compat even if our oracle version number
15) 69-70 byte 0000 --- Is kfdhdb.dsknum Even
if the disk numer value range 0 to 65335 16) 71 byte 01 --- here corresponds to kfdhdb.grptyp, i.e. the redundancy of the disk group 01 means EXTERNAL redundancy
The following adds the properties of this value:
KFDGTP_INVALID ((kfdgtp)0) -- Illegal
value
KFDGTP_EXTERNAL (kfdgtp)1) -- External redundancy KFDGTP_NORMAL (kfdgtp)2) -- Normal
redundancy KFDGTP_HIGH (kfdgtp)3) -- High
redsend 17, 72 Byte 03 --- the corresponding here is kfdhhdb.hdrsts i.e. the state of the disk group 03 indicates normal (very important here)
Add to the familiarity of the value change:
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 of the member group ---03 OK
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 preparedbeforehand
18) 73rd to 104th byte 44415441 to 0000000000 32 byte --- which corresponds to kfdhdb.dskname i.e. disk name we Here DATA01_0000
19) 105th to 136th byte 44415441 to 00000000000 32 byte --- corresponding to kfdhdb.gr pname is the disk group name DATA01
20) 137 to
168 byte is also the beginning of the 44415441 32 byte --- here corresponds to kfdhdb.fgna Me is failgroup name 21) 169 to 184 byte a total of 16 byte --- here corresponds to kfdhdb.capname is Capategroup name Of course I
don't use 22) 185 to 188 byte a total of 4 byte --- here corresponds to
kfdhdb.crestmp.hi i.e. Creation timestamp high 23) 189 to 192 byte
a total of 4 byte --- here corresponds to kfdhdb.crestmp.lo i.e. Creation
timestamp low 24) 193-196 byte a total of 4 byte --- here corresponds
to kfdhdb.mntstmp.hi 25) 197 to 200 byte a total of 4 byte --- here corresponds to kfdhdb.mntstmp.lo 26) 201 to 202 a total of 2 byte --- Here corresponds to kfdhdb.secsize i.e.physical sector size of the
disk 27) 203 to 204 a total of 2 byte --- here
corresponds to fdhdb.blksize i.e. the size of the datatata blocks block 28) 205
to 208 a total of 4 byte --- here Corresponding to kfdhdb.ausize i.e. AU size
1048576 i.e. 1m 29) 209 to 212 a total of 4 byte --- here corresponding to kfdhdb.mfact i.e. Stride physical addresses of the allocation units 30) 213 to 216 a total of 4 byte -- -The corresponding here is kfdhdb.dsksize i.e. 0x00001400 converted to 10 feed for 5120
i.e. 5120 allocated units s
disk group size
Supplement: kfdhdb.ausize s dsksize_kfdhdb s disksize i.e. 1m x 5120 s 5120m (Note that this size is the entire disk group.) Size)
31) 217-220 A total of 4 byte --- here corresponds to kfdhdb.pmcnt here the value is 2 i.e. Number of physically addressed allocation units
32) 221 to 224 a total of 4 byte --- here corresponds to kfdhdb.fstlocn That is, First FreeSpace table block number used to find freespace.
33) 225-228 A total of 4 byte --- here corresponds to kfdhdb.altlocn i.e. First
Alocation table block numer used to find allocated space 34) 229 to 232 a total of 4 --- here corresponds to kfdhdb.f1blocn i.e. File Directory block 1 Allocation. Beginging for
filedirectory is the first file
directory usually here is 2 35) 241 to 244 a total of 4 byte ---
here corresponds to kfdhdb.dbcompat conversion is our database version 36) 245
to 248 a total of 4 byte --- > 2010 0xb --
> 11
0x8 -- >8 -- is the value here for kfdhdb.grpstmp.hi, which is the value of HOUR-0x15 DAYS-0x8 MNTH-0xbYEAR-0x7da 0x7da
0x15 -->21
i.e. 2010/11/08 21 Here's just exactly to
hours 37) 249 to 252 A total of
4 byte --- here corresponds to kfdhdb.grpstmp.lo Our value here
is USEC,0x0 MSEC-0x2c6S ECS-0x17 MINS-0x29 MINS-0x29 -- >41
minutes SECS-0x17 -- >23 seconds
MSEC-0x2c6 -- >710 microseconds, or 0.7s
USEC,0x0 -- >0
the key here is to figure out how these values are calculated. add the calculation method here, interested can also calculate their own.
Earlier we pasted the results of the KFED display div header:
[[email protected] ~]$ kfed read/dev/mapper/datap1
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=0x8NUMB=0x0
kfbh.check: 1508168608 ; 0x00c:0x59e4d3a0
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0; 0x01c: 0x00000000
each line has a 16-way value and content. 16 feed is the corresponding start bytes.
as:
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0; 0x01c: 0x00000000
0x018 corresponding to the 10-in is 24, 0x01c the corresponding 10-in is 28. so 24-27bytes is kfbh.spare1.
To understand this, we can use BBED to modify, or to modify div header using KFED, and then go back to the merge. This also handles the failure of the disk header. There is a separate note about disk header troubleshooting.
-------------------------------------------------------------------------------------------------------
QQ:492913789
Email:[email protected]
Blog: http://www.cndba.cn/dave
Weibo: http://weibo.com/tianlesoftware
Twitter: http://twitter.com/tianlesoftware
Facebook: http://www.facebook.com/tianlesoftware
Linkedin: http://cn.linkedin.com/in/tianlesoftware
DBA1 GROUP: 62697716 (FULL); DBA2 GROUP: 62697977 (FULL) DBA3 GROUP: 62697850 (FULL)
DBA SUPERGROUP: 63306533 (FULL); DBA4 GROUP: 83829929 (FULL) DBA5 GROUP: 142216823 (FULL)
DBA6 GROUP: 158654907 (FULL) DBA7 GROUP: 69087192 (FULL) DBA8 GROUP: 172855474
DBA SUPERGROUP 2: 151508914 DBA9 GROUP: 102954821 CHAT GROUP: 40132017 (FULL)
--Adding groups is required to explain the relationship between Oracle table space and data files in the notes, otherwise the request will be rejected