Any change in the storage configuration like disk addition or dropping will trigger a oracle ASM rebalance operation The main objective of the oracle ASM rebalance operation is to always provide an even distribution of file extents and space usage across all disks in the diskgroup. Rebalancing is performed on all database files on a per file basis. The Oracle background process, RBAL, from the ASM instance manages this rebalance.
Process flow for ASM rebalancing:
1. On the ASM instance, a disk is added or dropped from a diskgroup.
2. This invokes the RBAL process to create the rebalance plan and then begin coordination of the
redistribution
3. RBAL will calculate estimation time and work required to perform the task and then message the
ARBx processes to actually handle the request. The number of ARBx processes invoked is
directly determined by the asm_power_limit.
4. The Continuing Operations Directory (metadata) will be updated to reflect a rebalance activity.
5. Each extent to be relocated is assigned to an ARBx process.
6. ARBx performs rebalance on these extents. Each extent is locked, relocated, and unlocked. This
is shown as Operation REBAL in V$ASM_OPERATION
The time of rebalance depends on the init.ora parameter asm_power_limit.The range of values for asm_power_limit are 0 to 11; where a value of 11 is full throttle and a value of 1 is low speed. A value of 0, which turns off automatic rebalance, should be used with caution.It is recommended that If removing or adding several disks, it is best to add or remove drives all at once, this will reduce the number rebalance operations that are needed for storage changes
Select * from v$asm_operation
When the ASM rebalance operation is completed, alert log will show one of these messages
Disk emptied
Disk header erased
PST update completed successfully
Disk closed
Rebalance completed
If you want to increase the rebalance power, we can give below command
alter diskgroup <diskgroup name> rebalance power <n>;
Known issues
You have a diskgroup with exactly same sized disks as seen in v$asm_disk.total_mb. You are seeing different values in v$asm_disk.free_mb for these disks.
Rebalance of the disk completes successfully without any issue. Check all no repair does not report any metadata discrepency.
Cause
From 11.1.0.7, we are allowing some percentage of imbalance among disks in a diskgroup to allow rebalance to do less work. This behavior is seen when we have large number of disks and a large number of small ASM files in a diskgroup.
Bug 7699985 and Bug 8451772 discusses about this default behavior on 11.1.0.7.
Solution
The issue should not be seen on 11.2 release.
On 11.1 we can use the workaround:
alter system set "_asm_imbalance_tolerance"=0; alter diskgroup rebalance power ; exit
Related Articles
Oracle ASM (Automatic Storage Management ) Introduction and How it works
ASM Initialization Parameters: ASM_DISKSTRING,ASM_DISKGROUPS
How to prepare the Oracle ASM disks
Oracle ASM Diskgroups : Create and Alter diskgroup
How ASM Failure Groups and CSS provides high availability