Resizing ASM Disks On Modern Systems. Real Application Clusters Doesn’t Make It Any More Difficult. An XtremIO Example With RAC.

My recent post about adding space to ASM disk groups by resizing them larger, as opposed to adding more disks, did not show a Real Application Clusters example. Readers’ comments suggested there is concern amongst DBAs that resizing disks (larger) in a RAC environment might somehow be more difficult than in non-RAC environments. This blog entry shows that, no, it is not more difficult. If anything is true it is that adding disks to ASM disk groups is, in fact, difficult and invasive and that resizing disks–whether clustered systems or not–is very simple. The entire point of this short blog series is to endear DBAs to the modern way of doing things.

For more background on the topics of LUN sizes and LUN counts in All-Flash Array environments based on proof and data from an XtremIO environment, I recommend the following links. The first and second links in the following list make the case for the fact that administrators really do not need to make ASM disk groups out of large numbers of host LUNS. The third link covers resizing ASM disks in a non-RAC environment.

  1. Yes, Host Aggregate I/O Queue Depth is Important. But Why Overdo It When Using All-Flash Array Technology? Complexity is Sometimes a Choice.
  2. Host I/O Queue Depth with XtremIO and SLOB Session Count. A Granular Look.
  3. Stop Constantly Adding Disks To Your ASM Disk Groups. Resize Your ASM Disks On All-Flash Array Storage. Adding Disks Is Really “The Y2K Way.” Here’s Why.

A Real Application Clusters Example

The example I give in this post is based on XtremIO storage array; however, the principles discussed in this post are applicable to most modern enterprise storage arrays. However, it is my assertion that adding space to ASM disk groups by resizing the individual ASM disks (LUNs) is really only something one should do in an All-Flash Array environment like XtremIO. I’ve made that point in the above-cited linked articles.

Resizing ASM disks in an XtremIO environment is every bit as simple as it is in non-RAC environments. The following example shows just how simple.

Figure 1 shows a screen capture of ASMCA reporting that all disk groups are mounting on both nodes of the RAC cluster and that the SALESDATA disk group has 2TB capacity at the beginning of the testing.


Figure 1

Figure 2 shows the XtremIO GUI after all 4 of the ASM disks in the SALESDATA disk group have been resized to 1TB. Resizing XtremIO volumes is a completely non-disruptive operation.


Figure 2

Figure 3 shows the simple commands the administrator needs to execute to rescan for block device changes on all nodes of the RAC cluster. Figure 3 also shows the commands necessary to verify that the block device reflects the new capacity given to each of the LUNs that map to the XtremIO volumes.


Figure 3

Figure 4 shows how a simple shell script (called in this example) can be used to direct the multipathd(8) command to resize internal metadata for specific XtremIO volumes. The script can be executed on remote hosts via the bash(1)  “-s” option.


Figure 4

Figure 5 shows how the ASM disks were 512GB each until the disk group was altered to resize all the disks. That is, in spite of the fact that the block devices were resized at the operating system level, ASM had not yet been updated.


Figure 5

Once the ASM disks are resized as shown in Figure 5, the ASMCA command will also show that the disk group (SALESDATA in the example) has 4TB capacity as seen in Figure 6.


Figure 6

This example has shown that resizing ASM disks in an XtremIO environment is the simplest, least impactful way to add space to an ASM disk group in a Real Application Clusters environment–just as it is in a non-RAC environment.





3 Responses to “Resizing ASM Disks On Modern Systems. Real Application Clusters Doesn’t Make It Any More Difficult. An XtremIO Example With RAC.”

  1. 1 Vince Poore (@VincePoore) September 1, 2016 at 11:31 am

    Ok, I’m behind the times but am willing to learn new things. I’m still using asmlib on Oracle Linux 5 and partitioning every device before presenting it to asmlib. Next year I will be rebuilding the Oracle RAC on 12c, OL7.

    I work for a medium size business. We have..
    * VNX5200 with 60 disk SAS, NL-SAS storage pool with 200G of SSD Fast Cache
    * 2 node Oracle 11g RAC
    * 4 500G LUNs from above storage pool
    * database performance is acceptable currently

    I like this idea of just growing LUNs to add space but we don’t have all flash.

    I’ll still be using the same VNX5200. Since our current performance is acceptable, it seems reasonable to ditch asmlib and partitioning of LUNs and go with the approach you have outlined here.

    I probably won’t have time to benchmark asmlib vs no-asmlib, should I be worried about that?

    • 2 kevinclosson September 2, 2016 at 8:40 am

      you’ll never see a performance delta between ASMLib and DM-MPIO with native OS async I/O (libaio).

      I’m worried that if you grow ASM disks in a non-AFA world you might add space that doesn’t have the precise same performance characteristics as the existing space. In other words, I’m worried about a Lumpy LUN. Do you feel that you have good control over growing a LUN on the VNX side such that the added space given to the LUN will boil down to uniform I/O performance to match the existing data in the LUN? If so then, sure, drop the partitions. Drop ASMLib no matter. It’s simply *not necessary*.

      Please let me know if I haven’t answered your question.

  1. 1 How Many ASM Disks Per Disk Group And Adding vs. Resizing ASM Disks In An All-Flash Array Environment | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on August 31, 2016 at 2:43 pm

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon. In other words, I work at Amazon, but this is my own opinion.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 744 other subscribers
Oracle ACE Program Status

Click It

website metrics

Fond Memories


All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.

%d bloggers like this: