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:
Disk header
Free Space Table (FST)
Allocation Table (AT)
Partnership and Status Table (PST)
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:
File Directory
Disk Directory
Active Change Directory (ACD)
Continuing Operations Directory (COD)
Template Directory
Alias Directory
ADVM Volume Directory
Disk Used Space Directory
Attributes Directory
ASM User Directory and User Group Directory
Staleness Directory and Staleness Registry
Password directory
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.