Installation guide
16
MB, depending on the specific disk group compatibility level. Larger AU sizes typically provide performance
advantages for data warehouse applications that use large sequential reads.
Oracle ASM 11gR2 introduced the concept of variable extents, which adds an extra layer of complexity when
determining the optimal AU size. The extent size of a file varies as follows:
Variable ASM extents used for Allocation Units
First 20,000 (0-19,999) AUs the extents size = 1AU
Next 20,000 (20,000 – 39,999) AUs the extent size = 8*1AUs
Then 40,000+ AUs the extents size = 64*1AUs
Figure 7 shows the Oracle ASM file extent relationship with allocation units. The first eight extents (0 to 7) are
distributed on four Oracle ASM disks and are equal to the AU size. After the first 20000 extent sets, the extent size
becomes 8*AU for the next 20000 extent sets (20000 - 39999). This is shown as bold rectangles labeled with the
extent set numbers 20000 to 20007, and so on. The next increment for an Oracle ASM extent is 64*AU.
Figure 7. HP Scalable Warehouse Solution for Oracle – DL980 recommended 8Gb FC HBA Slot Loading
The automatic allocation of extent sizes was found to be an issue when performing testing and can likely cause issues
on other storage arrays as well when very large ASM diskgroups are created. Large ASM diskgroups are typical for
many Business Intelligence and data warehouse implementations. One way of avoiding this “growing” extent
problem is to first create the diskgroup and then apply the Oracle ASM underscore parameter _extent_counts to
negate extent growth. This can only be done after the diskgroup is created, and also needs to be done before any
data is placed in the ASM diskgroup, to avoid potential performance issues. It is an attribute of this specific diskgroup
needed to keep a consistent extent size.
When creating a disk group, add the “set attribute” clause to force fixed size striping. Variable extents sizes can be
disabled on an ASM diskgroup after creation by issuing the following Oracle command.
alter diskgroup <diskgroup name> set attribute '_extent_counts'='214748367 0 0';
Next some testing was done to determine the optimum ASM AU size for data layout on the P2000 for BI/DW
workloads. Tests were done using 1, 4, 16 and 64MB units of allocation as shown in figure 8. Clearly for our
environment the uniform ASM AU size of 64MB achieved the best I/O results at nearly 18GB/sec for table scans. It
was also found that using tablespace uniform extent size of 64MB and table uniform extent size of 64MB yielded the
best results. However not nearly as dramatic a difference as it was with uniform ASM AU sizes, if the tablespace
extent size was 16MB or greater (defined in increment factors of 2) it produced virtually identical results to 64MB