Oracle ASM (Automatic Storage Management) is a volume manager and file system provided by Oracle for use with Single Instance and Real Application Cluster (RAC) databases. Although it supports single instance databases I’ve seen it more commonly used with RAC. ASM provides a high performance and simplified way of managing disks and placing data files and other files for DBA’s. It probably comes as no surprise that Oracle recommends ASM over other options such as OS included or third party volume managers, file systems and raw devices. The ASM Allocation Unit is a fundamental unit of storage and management in any ASM disk group. But which Allocation Unit size should you choose for your Virtualized Oracle Databases?

The answer is actually quite simple, for me at least – “It depends”. The ASM AU (allocation unit) can have an impact on the performance of your database and your underlying storage and depending on your database workload. The default ASM AU size is 1MB. I’ll give you the best practices that I’ve used successfully over a number of implementations around the world.

There is one rule that I always recommend when it comes to ASM, the AU size should be equal to, or a multiple of your underlying storage block size. In a vSphere environment with VMFS5, if it’s a freshly created datastore, that’ll be 1MB or a multiple of 1MB. For VMFS3 (or upgraded VMFS5) you might have a VMFS block size of 8MB, in which case you might want to use an ASM AU of 8MB. A larger ASM AU can improve the performance of sequential read IO accesses and reduce the number of overall allocation units that needs to be managed for a given disk group size. Sequential IO access is important for data warehouse workloads, or poorly written schemas that do lots of full table scans.

Here is a picture of the ASM Disk Group Configuration screen, with the ASM AU size selection box expanded (from 12c, but similar to 11g):

As you can see the options for the ASM AU are 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, and 64MB (was 1MB for Oracle 10g). For Data Files and most other storage areas my ASM AU of choice is 4MB or 8MB. 4MB is Oracle’s recommendation since 11g, and this works well with VMFS datastores. The goal is to have it small enough that the AU’s are not too hot and large enough for good sequential read IO. 8MB might provide better performance if you think your database will be large, as there will be less units to manage.

Assuming you’re using Linux for your Oracle Database you should consider tuning the max_sectors_kb value to be equal to 1MB or your ASM AU size. This will increase the maximum IO size that the operating system will issue. You may also want to look at tuning read_ahead_kb to improve sequential IO (such as REDO). This value is tunable in the /sys/sdX/block/queue (where X = your device letter) filesystem and can’t be larger than max_hw_sectors_kb. Bear in mind that vSphere limits the maximum IO size to 20MB, so regardless of what you set in your VM your IO size can never exceed 20MB before it’s split. With IO transfers of this size you should expect high latency as well, which is fine for large sequential IO. Most block devices will have an IO size limit of less than 20MB in any case. If you set these values manually they will not persist across reboots. You may want to add a command to rc.local to resolve this.

For Nutanix Environments I recommend you set your ASM AU size to 1MB as this aligns with the Nutanix Distributed File System (NDFS) Extent Size. In NDFS an extent is 1MB and an extent group is 4MB. I would recommend that you set max_sectors_kb to 1MB, to align with the extent size in NDFS. This also aligns nicely with ASM as an ASM extent is a minimum of 1 AU. Going above these values could cause issues with newer Linux kernels that have changed max IO sizes.

Final Word

Keep It Simple and Standard. Whatever you decide is the best for your environment it’s best to keep it simple and standard. For most cases 1MB ASM AU will be a good fit for performance. If you are virtualizing a large data warehouse or decision support system, then you may want to look at significantly increasing the AU size, at least for the main data file storage. As always your feedback is welcome and appreciated. I’d love to hear your experience around working with different ASM AU sizes.

—

This post appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.