The views expressed on this blog are my own and do not necessarily reflect the views of Oracle

April 26, 2010

ASM metadata


An ASM instance manages metadata needed to make ASM files available to Oracle databases and ASM clients. ASM metadata is stored in disk groups – in metadata blocks.

Some ASM metadata is at the fixed position in every ASM disk, and is referred to as physically addressed metadata. Other ASM metadata is organised in files (directories) and is referred to as virtually addressed metadata. The virtually addressed metadata is managed like all other ASM files – they get mirrored as per the file type redundancy policy, are subject to rebalance and can grow as needed.

Each ASM disk has ASM metadata, with some of this metadata relevant to that disk only and some relevant to the whole disk group. For example, the ASM disk header is relevant to that disk only, while  the Partnership and Status Table (PST) is relevant to the whole disk group.

Physically addressed metadata

The physical ASM metadata are the following structures:
Allocation units 0 on every ASM disk will always have the disk header (block 0), the Free Space Table (block 1) and the Allocation Table - in the rest of the allocation unit 0 blocks.

Allocation unit 1 (AU1) on every ASM disk is always reserved for the Partnership and Status Table. While AU1 on every disk will be reserved - only some disks will have the actual PST data.

Virtually addressed metadata

The virtually addressed metadata are the following structures:

ASM metadata lives in ASM disk groups

ASM metadata is stored in disk groups - in other words if there are no disk groups there is no ASM metadata.  This sounds obvious, but the point is that ASM does not store anything outside of its disk groups.

Each ASM disk has ASM metadata. Some of this metadata is relevant to that disk only and some is relevant to the whole disk group. For example, the ASM disk header is relevant to that disk only, but the partnership and status table (PST) is relevant to the whole disk group.

Some metadata will be on every disk - e.g. a disk header and an allocation table. Other metadata will be on a subset of disks - e.g. allocation unit 1 on every ASM disk will be reserved for the PST, but only a subset of disks will actually have the PST data.

Some metadata will not be present at all - e.g. in a 10.2 disk group there will be no staleness directory, as that feature is only relevant to 11.1 and later version.  And even in 11.1 - an external redundancy disk group will not have the staleness directory as that feature is relevant to a normal and high redundancy disk groups only.

ASM metadata blocks

ASM metadata is organized in ASM metadata blocks. For a complete discussion on this topic please see the ASM metadata blocks post.

ASM metadata structures consist of one or more ASM metadata blocks - where the block type will match the ASM metadata type.  For example an ASM disk header will consist of exactly one metadata block of type KFBTYP_DISKHEAD; an allocation table will consist of a number of metadata blocks, all of type KFBTYP_ALLOCTBL, etc.

3 comments:

  1. Hi Bane,

    I currently work in Oracle ACS and we've had an issue with a customer whereby one metadata block within the allocation table of AU0 has become corrupt. We are trying to decipher when the last time this block would have been read. The block is block 48 and it appears that parts of the block have been zeroed.
    When is ASM metadata read? It is my understanding that on disk add block 0, the disk header is read. So is block 48 only read upon a rebalance?
    Many thanks,
    Kerri

    ReplyDelete
    Replies
    1. Hi Kerri,
      ASM will access the allocation table on operations that require space allocation/deallocation. That can be on add/remove file, resize file, rebalance, etc.
      I don't think you would be able to work out when that block was read, and frankly that is not relevant. You can try disk group repair (ALTER DISKGROUP REPAIR) to see if this can be corrected by ASM. I assume this is an external redundancy disk group, as with normal/high redundancy we can easily get around this.
      Cheers,
      Bane

      Delete
  2. Thanks Bane,
    We have recovered the database so it's a RCA process now.
    I'm really impressed with your fast response.
    Many thanks,
    Kerri

    ReplyDelete