Oracle ASM Migration To A New Storage Platform With No Downtime

Is it about that time to replace your old storage – which stores your important business applications – but you are worried about the extended downtime of migrating your ASM diskgroups to the new storage? 

Oracle supports no downtime when migrating from your old storage platform to a new storage platform. Whether you are using direct attached storage (DAS), network attached storage (NAS) or storage area networks (SANs) the following process is available and well supported.

No downtime Oracle ASM migration will work for all ASM files including OCR, Votefiles and ASM spfile. ASM diskgroups are configured on creation to specify a level of redundancy of external, normal or high redundancy.  The process for migration to new storage is the same no matter the level of redundancy configured for the ASM diskgroup.

There are 3 possible methods:

1. Adding all new disks and dropping all old disks – 2 commands and 2 rebalances.

alter diskgroup <diskgroup name> add disk

‘<new disk 1>’, ..,‘<new disk N>’ rebalance power <#>;

alter diskgroup <diskgroup name> drop disk

<old disk 1>, ..,<old disk N>  rebalance power <#>;

2  Adding all new disks and dropping all old disks – 1 command and 1 rebalance.

E.g. alter diskgroup <diskgroup name>

add disk ‘< new disk 1>’, .., ‘< new disk N >’

drop disk <old disk 1>, ..,<old disk N>  rebalance power <#>;

3 Using the replace command – 1 command and 1 rebalance.  Only available from Oracle 12c.

E.g. alter diskgroup <diskgroup name> replace disk <disk name> with ‘<new disk 1>’ power <#>;

Option 2 and 3 are more efficient as there is only 1 rebalance. Make sure the option selected above is tested before running in a production environment.

When disks are added/removed/resized ASM will rebalance the data across all disks in that ASM diskgroup.  The rebalance power defaults to the ASM_POWER_LIMIT parameter which has the default setting of 1.  The rebalance power can be modified dynamically, the higher the value the more likely the operation will complete sooner but also the likelihood that more I/O resources are used.  If using a high rebalance power then monitor your I/O as this could affect other systems if using shared storage.  The disable power limit depends on the setting of the disk group attribute COMPATIBLE.ASM, 11.2.0.2 or higher (power can be set from 0 to 1024) otherwise all earlier versions (power can bet set from 0 to 11).  After the rebalance is completed all disks should have the header_status of ‘FORMER’ from the v$asm_disk view.  Setting a power limit of 0 will disable rebalancing. E.g.  alter diskgroup diskgroup_name> rebalance power <#>;

Considerations during storage migrations:

• Performance Tests against new storage using the likes of swingbench, Orion or Callibrate IO
• ASM LUN size should be all the same size and characteristics.
• Creating a temporary diskgroup to test new disks.
• Use ‘kfed read’ utility to analyse ASM disk header information from each node.
• Server Reboots to the new configuration and ensure clean restarts.
• Backup the Oracle Cluster Register (OCR) – before any cluster changes.