【转】How many allocation units per file

This post is about the amount of space allocated to ASM based files. The smallest amount of space ASM allocates is an allocation unit (AU). The default AU size is 1 MB, except in Exadata where the default AU size is 4 MB. The space for ASM based files is allocated in extents, which consist of one or more AUs. In version 11.2, the first 20000 extents consist of 1 AU, next 20000 extents have 4 AUs, and extents beyond that have 16 AUs. This is known as variable size extent feature. In version 11.1, the extent growth was 1-8-64 AUs. In version 10, we don't have variable size extents, so all extents sizes are exactly 1 AU. Bytes vs space The definition for V$ASM_FILE view says the following for BYTES and SPACE columns:

• BYTES - Number of bytes in the file
• SPACE - Number of bytes allocated to the file

There is a subtle difference in the definition and very large difference in numbers. Let's have a closer look. For the examples in this post I will use database and ASM version 11.2.0.3, with ASMLIB based disks. First get some basic info about disk group DATA where most of my datafiles are. Run the following SQL connected to the database instance. Now create one small file (under 60 extents) and one large file (over 60 extents). Get the ASM file numbers for those two files: The small file is ASM file number 272 and the large file is ASM file number 271. Get the bytes and space information (in AUs) for these two files. For the large file, bytes shows the file size is 100 AUs = 100 MB. So far so good. But the space required for the large file is 205 AUs, not 202 as one might expect. What are those extra 3 AUs for? Let's find out. ASM space The following query (run in ASM instance) will show us the extent distribution for ASM file 271. As the file is mirrored, we see that each virtual extent has two physical extents. But the interesting part of the result are the last three allocation units for virtual extent number 2147483648, that is triple mirrored. We will have a closer look at those with kfed, and for that we will need disk names. Get the disk names. Let's now check what type of data is in those allocation units. These additional allocation units hold ASM metadata for the large file. More specifically they holdextent map information that could not fit into the the ASM file directory block. The file directory needs extra space to keep track of files larger than 60 extents, so it needs an additional allocation unit to do so. While the file directory needs only few extra ASM metadata blocks, the smallest unit of space the ASM can allocate is an AU. And because this is metadata, this AU is triple mirrored (even in a normal redundancy disk group), hence 3 extra allocation units for the large file. In an external redundancy disk group, there would be only one extra AU per large file. Conclusion The amount of space ASM needs for a file, depends on two factors - the file size and the disk group redundancy. In an external redundancy disk group, the required space will be the file size + 1 AU for the file header + 1 AU for indirect extents if the file is larger than 60 AUs. In a normal redundancy disk group, the required space will be twice the file size + 2 AUs for the file header + 3 AUs for indirect extents if the file is larger than 60 AUs. In a high redundancy disk group, the required space will be three times the file size + 3 AUs for the file header + 3 AUs for indirect extents if the file is larger than 60 AUs.