Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

2543

May 16th, 2012 23:00

Oracle Storage Migration without Downtime

In case I have a Oracle 11g with ASM running on an old SAN storage, and now I would like to migrate all database data to a new SAN stoage.  Is it possible to make this migration no downtime?  If yes, are there any steps to follow?

11 Posts

May 17th, 2012 03:00

In case you are using Oracle ASM, it's convenient to migrate your oracle disks from one storage to another by using Oracle ASM add / drop disks and rebalance feature.

The main steps are:

1. Attach the disks from the new storage array to your database server

2. Add the disks from the new storage array to your ASM diskgroup

3. Drop the ASM disks from the old storage array

4. During add / drop ASM disks, tune the rebalance power to manage the speed of data migration.

643 Posts

May 19th, 2012 19:00

Thanks Neil!  Very smart way for migration.  ASM rebalance is important part of the whole process.  Could you please share more detail on how to tune the rebalance power?

11 Posts

May 20th, 2012 22:00

ASM automatically rebalances when the configuration of a disk group changes. By default, the ALTER DISKGROUP statement does not wait until the operation is complete before returning. Query the V$ASM_OPERATION view to monitor the status of this operation.

To control the speed and resource consumption of the rebalance operation, you can include the REBALANCE POWER clause in statements that add, drop, or resize disks. The POWER clause of the ALTER DISKGROUP...REBALANCE statement specifies the degree of parallelism, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11. A value of 0 halts a rebalancing operation until the statement is either implicitly or explicitly re-run. The default rebalance power is set by the ASM_POWER_LIMIT initialization parameter.

The following example manually rebalances the disk group DATA:

ALTER DISKGROUP DATA REBALANCE POWER 11;

643 Posts

May 21st, 2012 01:00

Thanks for your explanation, Neil!

The Rebalance operation provides an even distribution of file extents across all disks in the diskgroup. The rebalance is done on each file to ensure balanced I/O load.

The RBAL background process manages the rebalance activity. It examines the extent map for each file and redistributes the extents to new storage configuration. The RBAL process will calculate estimation time and the work required to perform the rebalance activity and then message the ARBx processes to actually perform the task. The number of ARBx process starts is determined by the parameter ASM_POWER_LIMIT.

There will be one I/O for each ARBx process at a time. Hence the impact of physical movement of file extents will be low. The asm_power_limit parameter determines the speed of the rebalance activity. It can have values between 0 and 11. If the value is 0 no rebalance occurs. If the value is 11 the rebalance takes place at full speed. The power value can also be set for specific rebalance activity using Alter Diskgroup statement.

No Events found!

Top