And now, we erase the header block of each disk. Header block is the first one of an ASM disk device, and its default size is 4096 bytes (This size is available in _asm_blksize undocumented parameter).

Well, let’s summarize … I erased the header block of both asm disks in my diskgroup without any impact on file extent allocation. The only impact I had was on the mount capability. Next, I have restored the header block of each disk with a kfed repair operation … yes, but without any backup of the disk or the disk header. So I wonder … where was the backup of my header block?

First, I will try a very simple method. I will have a look at all metadata blocks in my asm disk device. I hope I will find another header block. For this purpose, i will use a basic shell script to analyze each block. If the script finds a block with the type KFBTYP_DISKHEAD, it will keep the block position, and print them at the end of script execution:

Ok, so there is a copy of the header block in the 510th block in my disk. Indeed, as Bane Radulović mentioned it in its blog, a backup copy of ASM disk header is in the second last block of allocation unit 1. So, if my AU is 1Mb and my block size 4096 bytes, a copy of my header block will be available in ((1048576 / 4096) * 2 – 1 = 511), as the block# starts at 0, it is located in the 510th block.

To double check this, I will erase the header block of my first ASM disk, and use kfed repair and strace to see what really happens:

First operation, it opens the device and read the block after 2088960 bytes. But 2088960/4096 = 510, so it reads the 510th block of the disk. Next it reads the block at position 0 (header block), and then writes in it the content of the 510th block.

Well, now I know there’s a copy of each header block in a secret position !!! (block #510) and kfed uses this block to repair the main header block.

During my tests, I noticed that sometimes, asm disks lost their asm label (I don’t know why). As a consequence, repaired disks won’t be recreated by the oracleasm scandisks (or after a reboot).

In a previous post, I explained how to dump ASM Disk header and how to analyze it. This method, which used kfed binary, is a little bit complex because of fields with a complex name extracted from the internal structure.

Another way to proceed and to see main information about asm disks is to use an undocumented binary located in $ORACLE_HOME/bin named amdu.

If amdu is not available in your $ORACLE_HOME/bin directory, you can build it with the next make command:

[oracle@oel ~]$ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk iamdu

To dump your ASM diskheader, you just have to execute this command with the -diskstring option and specify the location of your ASM disk devices (default uses ASM lib directory):

* kfdhdb.hdrsts: header status. Here, the disk is a member of the diskgroup.

* kfdhdb.dskname: disk name in the disk group

* kfdhdb.grpname: disk group name

* kfdhdb.fgname: failure group name which owns the disk

* kfdhdb.secsize: sector size

* kfdhdb.blksize: block size

* kfdhdb.ausize: allocation unit size

If you want to rename the diskgroup the disk belongs to, you can edit the dumpfile and use the “merge” command of KFED to apply changes to the disk header.

[oracle@oel ~]$ kfed merge /dev/oracleasm/disks/ASM3 text=dsk1.dump

Be careful when you use the “merge” command because, it seems the diskgroup name, or disk name is coded with a fixed length, so if you change the name, and this one is based on a 4 bytes word, rename it to a 4 bytes word.

DISCLAIMER

The views expressed on this blog are my own and do not reflect the views of the company(ies) I work (or have worked for) neither Oracle Corporation. The opinions expressed by visitors on this blog are theirs, not mine.

The information in this blog is written based on personal experiences. You are free to use the information on this blog but I am not responsible and will not compensate to you if you ever happen to suffer a loss/inconvenience/damage because of/while making use of this information.