瞭解和使用kfed維護ASM後設資料
以下是轉載的兩篇文章,這兩篇文章分別介紹了kfed工具和ASM磁碟頭,兩篇文章之間有很強的關聯性,所以在這裡一併貼出。
1.kfed - ASM metadata editor
The kfed is an undocumented ASM utility that can be used to
read and modify ASM metadata blocks. It is a standalone
utility, independent of ASM instance, so it can be used with either mounted or
dismounted disk groups. The most powerful kfed feature is its ability to fix
corrupt ASM metadata.
The kfed binary is present in the recent ASM versions, but if you don't see it
in your $ORACLE_HOME/bin directory (e.g. it may not be present in
version 10.1), it can be built as follows:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins* ikfed
kfed read
With the kfed read command we can read a single ASM metadata block. The
syntax is:
$ kfed read [aun=ii aus=jj blkn=kk dev=]asm_disk_name
Where the command line parameters are
· aun - Allocation Unit (AU) number to read from. Default is AU0, or the very beginning of the ASM disk.
· aus - AU size. Default is 1048576 (1MB). Specify the aus when reading from a disk group with non-default AU size.
· blkn - block number to read. Default is block 0, or the very first block of the AU.
· dev - ASM disk or device name. Note that the keyword dev can be omitted, but the ASM disk name is mandatory.
Use kfed to read ASM disk header block
The following is an example of using the kfed utility to read the ASM disk
header from ASM disk /dev/sda1.
$ kfed read /dev/sda1 | more
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:
3102721733 ; 0x00c: 0xb8efc6c5
kfbh.fcn.base:
0 ; 0x010: 0x00000000
kfbh.fcn.wrap:
0 ; 0x014: 0x00000000
...
kfdhdb.dsknum:
0 ; 0x024: 0x0000
kfdhdb.grptyp:
2 ; 0x026: KFDGTP_NORMAL
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
kfdhdb.ausize:
1048576 ; 0x0bc: 0x00100000
kfdhdb.dsksize:
12284 ; 0x0c4: 0x00002ffc
...
Note that the above kfed command is equivalent to this one (with all parameters
explicitly set to their default values):
$ kfed read aun=0 aus=1048576 blkn=0 dev=/dev/sda1
We see that the above kfed output is nicely formatted and human readable (sort
of). The fields are grouped based on the actual content of the ASM metadata
block.
In this example, the kfbh fields show the block header data,
and the most important one is kfbh.type, which says KFBTYP_DISKHEAD, meaning
the ASM disk header. This is the expected block type for an ASM disk header.
We then see the actual content of the ASM disk header metadata block - the
kfdhdb fields. Some of those are the disk number (kfdhdb.dsknum), 0 in this
case, the group redundancy type (kfdhdb.grptyp), normal redundancy in this
case, the disk header status (kfdhdb.hdrsts), member in this case, the disk
name (kfdhdb.dskname) - DATA_0000, etc.
Please see ASM disk header for the complete
explanation of kfdhdb fields.
Use kfed to read any ASM metadata block
The next example shows how to read an ASM File Directory block. To do
that we would use the following kfed command:
$ kfed read aun=10 blkn=1 dev=/dev/sda1
| more
kfbh.endian:
1 ; 0x000: 0x01
kfbh.hard:
130 ; 0x001: 0x82
kfbh.type:
4 ; 0x002: KFBTYP_FILEDIR
...
Note that I had to specify AU10 and block 1 to read a File Directory block. Have a look at the ASM File Directory post to learn how to locate a File Directory block.
Is my ASM metadata block corrupt
If you see kfbh.type=KFBTYP_INVALID, in the disk header on a disk you believe
belongs to an ASM disk group, that indicates that the ASM disk header is
corrupt. But don't jump to conclusions! Are you looking at the right disk? Is
this the right disk partition? Can you access that disk via some other name -
in a multipath setup? If you are not sure, or if the disk header is in fact
damaged, contact Oracle Support for assistance.
Note that this applies to any ASM metadata block. If ASM expects to find a
metadata block and instead finds a block that is zeroed out or contains
rubbish, it will report the block as KFBTYP_INVALID, and an error (usually
ORA-15196) will be reported in the ASM and/or database alert log (depends on
which instance discovers the problem).
kfed write
With the kfed write command we can write to a single ASM metadata block. The
syntax is:
$ kfed write [aun=ii aus=jj blkn=kk dev=]asm_disk_name text=new_contents chksum=yes
Where the new command line parameters are
· text - a text file with the new block contents
· checksum=yes - calculate and write the correct checksum. Note that the checksum in the text file with the new content does not have to be correct.
Use kfed to write the correct checksum to ASM metadata
block
An ASM metadata may look fine, but in fact be corrupt. For
example the block checksum (kfbh.check) could be wrong, in which case that
would need to be corrected. Indeed, if the only problem is an
incorrect checksum, that can be easily corrected by simply reading the block
and then writing it back! The kfed will calculate the new checksum and write
the block back with the correct checksum.
Here are the complete steps to correct the bad checksum for block 2 in AU0 on
disk /dev/sda1:
$ kfed read aun=0 blkn=2 dev=/dev/sda1
> /tmp/aun0_blkn2_sda1.kfed
$ kfed write aun=0 blkn=2 dev=/dev/sda1 text=/tmp/aun0_blkn2_sda1.kfed
chksum=yes
NOTE: Please seek Oracle Support assistance with any suspected ASM metadata
block corruption.
kfed find
The kfed find will examine all blocks in an allocation unit and report back on
the block types found. The syntax is:
$ kfed find [aun=ii aus=jj dev=]asm_disk_name
We see that the find command parameters are the same as for the read command,
but the difference is that the find operates on all blocks in an allocation
unit.
Use kfed find command to verify blocks in AU0
This is an example of using the kfed find to verify that all blocks in AU0 have
the expected ASM metadata.
$ kfed find /dev/sda1
The expected result is type 1 for block 0, type 2 for block 1 and type 3 for
all other blocks, i.e.:
$ kfed find /dev/sda1
Block 0 has type 1
Block 1 has type 2
Block 2 has type 3
Block 3 has type 3
Block 4 has type 3
...
Block 255 has type 3
If you see anything else in the output, that indicates a corrupted ASM metadata
block. In that case please seek assistance from Oracle Support.
Note that my allocation unit size is 1MB, so there are only 255 blocks in the
AU. If your allocation unit size is 4MB, the same command should return block
type information for 1024 blocks.
I should also point out that with the above find command we only looked at the
expected ASM metadata block types. We did not look at the actual
metadata block contents. Some ASM metadata block corruptions are indeed with
the block contents, i.e the block type is correct, but the contents is wrong.
Such corruptions are only detected when ASM reads the corrupt block, in which
case an ORA-15196 error will be reported. Please seek assistance from Oracle
Support if you are unfortunate enough to encounter that error.
Conclusion
The kfed if an unassuming but very powerful utility. While I have shown only
few commands, the kfed can also format an empty ASM file, perform a sanity
check on an ASM metadata block, display data structure sizes and perform few
other more obscure operations.
2.ASM disk header
ASM disk header is probably the best known piece
of ASM metadata. Chances are you learned about it
when it was damaged or lost and hopefully Oracle Support was able to get you up
and running. In this post I will try to explain why ASM disk header is
important and what it contains.
Block zero
ASM disks are formatted into Allocation Units. Some Allocation units
contain ASM metadata and some contain database data. Allocation units that
contain ASM metadata are formatted into ASM metadata blocks. Allocation
unit 0 is at the beginning of an ASM disk and it always contain ASM
metadata. The very first block (block 0) of Allocation Unit
0 contains the ASM disk header.
ASM disk header contents
Most of the data in the ASM disk header is of interest to that disk only. But
some information in the ASM disk header is relevant to the whole disk group and
some is even relevant to the whole cluster!
Let's use kfed to have a closer look at block 0 of
an ASMLIB disk on Linux.
$ kfed read /dev/oracleasm/disks/ASMD1
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: 473773689 ; 0x00c: 0x1c3d3679
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: ORCLDISKASMD1 ; 0x000: length=13
kfdhdb.driver.reserved[0]: 1145918273 ; 0x008: 0x444d5341
kfdhdb.driver.reserved[1]: 49 ; 0x00c: 0x00000031
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: 186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: ASMD1 ; 0x028: length=5
kfdhdb.grpname: DATA ; 0x048: length=4
kfdhdb.fgname: ASMD1 ; 0x068: length=5
...
The result of the above kfed command shows us that this ASM block has two
types of data - block header data - prefixed with kfbh,
and ASM disk header data - prefixed with kfdhdb.
In fact, everyASM metadata block will have the block header
data plus the data specific to its block type.
Important ASM metadata block 0 header data
Data type |
Value |
kfbh.endian |
System endianness. 0 - big endian, 1 - little endian. |
kfbh.type |
ASM block type. KFBTYP_DISKHEAD tells us this is an ASM disk header block. |
kfbh.block.blk |
ASM block number. Note the ASM disk header is block number 0. |
Important ASM disk header specific data
Data type |
Value |
kfdhdb.driver.provstr |
ORCLDISK+[ASM disk name] for ASMLIB disks. ORCLDISK for non-ASMLIB disks. |
kfdhdb.dsknum |
ASM disk number. |
kfdhdb.grptyp |
Disk group redundancy. KFDGTP_EXTERNAL - external, KFDGTP_NORMAL - normal, KFDGTP_HIGH - high. |
kfdhdb.hdrsts |
ASM disk header status. For possible values see V$ASM_DISK.HEADER_STATUS. |
kfdhdb.dskname |
ASM disk name. |
kfdhdb.grpname |
ASM disk group name. |
kfdhdb.fgname |
ASM failgroup name. |
kfdhdb.crestmp.hi|lo |
The date and time disk was added to the disk group. |
kfdhdb.mntstmp.hi|lo |
Last time the disk was mounted. |
kfdhdb.secsize |
Disk sector size (bytes). |
kfdhdb.blksize |
ASM metadata block size (bytes). |
kfdhdb.ausize |
Alloocation unit size (bytes). 1 MB is the default allocation unit size. |
kfdhdb.dsksize |
Disk size (allocation units). In this case the disk size is 10239 MB. |
kfdhdb.fstlocn |
Pointer to ASM Free Space Table. 1 = ASM block 1 in this allocation unit. |
kfdhdb.altlocn |
Pointer to ASM Allocation Table. 2 = ASM block 2 in this allocation unit. |
kfdhdb.f1b1locn |
Pointer to ASM File Directory. 2 = allocation unit 2. |
kfdhdb.dbcompat |
Minimum database version. 0x0a100000 = 10.1. |
kfdhdb.grpstmp.hi|lo |
The date and time the disk group was created. |
kfdhdb.vfstart|vfend |
Start and end allocation unit number for the clusterware voting disk. If this is zero, the disk does not have voting disk data. Version 11.2 and later only. |
kfdhdb.spfile |
Allocation unit number of the ASM spfile. Version 11.2 and later only. |
kfdhdb.spfflg |
ASM spfile flag. If this is 1, the ASM spfile is on this disk in allocation unit kfdhdb.spfile. Version 11.2 and later only. |
ASM disk header backup
In ASM versions 11.1.0.7 and later, the ASM disk header block is backed up in
the second last ASM metadata block in the allocation unit 1. To work out the
second last block number we need to know the allocation unit
size and ASM metadata block size.
I talked about this in my post on kfed, but let's do that again - get those
values from the block header and calculate the second last block number in
allocation unit 1:
$ ausize=`kfed read
/dev/oracleasm/disks/ASMD1 | grep ausize | tr -s ' ' | cut -d' ' -f2`
$ blksize=`kfed read /dev/oracleasm/disks/ASMD1 | grep blksize | tr -s ' ' |
cut -d' ' -f2`
$ let n=$ausize/$blksize-2
$ echo $n
254
$ kfed read /dev/oracleasm/disks/ASMD1 aun=1 blkn=254
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: 473773689 ; 0x00c: 0x1c3d3679
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: ORCLDISKASMD1 ; 0x000: length=13
...
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: ASMD1 ; 0x028: length=5
kfdhdb.grpname: DATA ; 0x048: length=4
kfdhdb.fgname: ASMD1 ; 0x068: length=5
...
So we see the same contents as in block 0 in allocation unit 0.
This can be very handy when the disk header is damaged or lost. All we have to do is run kfed repair [disk_name], and specify the allocation unit size if the value is not default (1MB). But as I said in the kfed post, please do not do this on your own - seek Oracle Support assistance if you suspect problems with ASM disk header.
ASM disk header in Exadata
ASM disks in Exadata are not exposed to the OS via device names. Instead they
can be accessed via special name - "o/[IP address]/[disk name]". The kfed understands that
syntax, so we can still use it in Exadata.
Let's have a look at the ASM disk header on an Exadata disk:
$ kfed read
o/192.168.10.9/DBFS_DG_CD_03_exadatacel01
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
...
kfdhdb.dskname:DBFS_DG_CD_03_EXADATACEL01 ; 0x028: length=26
kfdhdb.grpname: DBFS_DG ; 0x048: length=7
kfdhdb.fgname: EXADATACEL01 ; 0x068: length=12
...
kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000
...
Some Exadata specific values in the ASM disk header are as follows:
· ASM disk name that consists of the disk group name (DBFS_DG), cell disk label (CD), cell disk number (3) and the storage cell name (exadatacel01)
· Failgroup name is the same as the storage cell name
· Default allocation unit size in Exadata is 4 MB
Conclusion
ASM disk header contains the metadata essential for the operation and
availability of an ASM disk group. To prevent the loss and accidental damage of
the ASM disk header, Oracle recommends to protect it by partitioning the disk -
thus 'moving' it away from the physical beginning of the disk. The ASM disk
header in Exadata is protected by not exposing it to the database server OS. In
ASM version 11.1.0.7 and later, the ASM disk header is further protected by
maintaining a copy in allocation unit 1.
文章來源:
http://asmsupportguy.blogspot.com/2010/04/kfed-asm-metadata-editor.html
http://asmsupportguy.blogspot.com.au/2011/08/asm-disk-header.html
另外還可以參考文章:《ASM tools used by Support : KFOD, KFED, AMDU (文件 ID 1485597.1)》
--end--
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28211342/viewspace-2147496/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 介紹Oracle自帶的一些ASM維護工具 (kfod/kfed/amdu)OracleASM
- 使用AMDU DUMP ASM磁碟後設資料資訊ASM
- 資料維護和基礎架構維護-有感架構
- ASM管理命令列三工具:KFOD、KFED和AMDUASM命令列
- Nagios資料提取和維護iOS
- 瞭解ASMASM
- ASM磁碟頭資訊損壞和修復(kfed/dd)ASM
- ASM管理命令列三工具:KFOD、KFED和AMDU(上)ASM命令列
- ASM管理命令列三工具:KFOD、KFED和AMDU(下)ASM命令列
- Oracle資料庫密碼檔案的使用和維護(轉)Oracle資料庫密碼
- ASM後設資料備份與恢復ASM
- 29. 使用MySQL之資料庫維護MySql資料庫
- ASM磁碟組丟失member kfed修復ASM
- 維護樹狀資料
- 維護資料庫安全資料庫
- 探索ORACLE之ASM04_維護OracleASM
- 白話大資料 | 元宇宙來了,但是你瞭解後設資料嗎?大資料元宇宙
- Oracle RAC系列之:ASM基本操作維護OracleASM
- ASM磁碟簡單維護,新增,刪除ASM
- 資料庫常用維護命令資料庫
- Oracle資料庫日常維護Oracle資料庫
- 深入FDO----資料維護
- 資料倉儲和後設資料
- Access資料庫日常維護和Access資料庫最佳化方法資料庫
- ASM tools used by Support : KFOD, KFED, AMDU (Doc ID 1485597.1)ASM
- ASMCMD執行ASM後設資料備份與還原ASM
- 自動儲存管理ASM日常維護(一)ASM
- 1.7. 建立和維護資料庫密碼檔案資料庫密碼
- [MySQL光速入門]029 資料庫管理和維護MySql資料庫
- Databricks 第6篇:Spark SQL 維護資料庫和表SparkSQL資料庫
- 六、資料庫管理與維護資料庫
- 合理使用後設資料工具,解決大資料治理落地難點大資料
- SAP RETAIL MM41維護商品主資料的時候可以維護分類資料AI
- 運維平臺的建設思考-後設資料管理運維
- 亞信科技AntDB資料庫——深入瞭解AntDB-M後設資料鎖的實現(一)資料庫
- 亞信科技AntDB資料庫——深入瞭解AntDB-M後設資料鎖的實現(二)資料庫
- 如何保護您不瞭解的資料資產免受網路攻擊?
- ASM檔案移出後的註冊和開啟資料庫ASM資料庫