Recently I have installed a new Oracle 12c database for testing purposes. I have had four 5 GB disks and by mistake I have configured all of them to create +DATA disk group in ASM.
Here is how my case looks like:
select group_number, disk_number, name, total_mb, free_mb, path
The state is presented on the chart below - four disks, all partially used.
All of them (asm-disk1, asm-disk2, asm-disk3, asm-disk4) belongs to GROUP_NUMBER=1 which is +DATA ASM diskgroup which can be confirmed by the following query:
select group_number, name, total_mb, free_mb
Then I thought about creating +FRA diskgroup to store recovery data there. As more than a half (13 of 20 GB) of the storage is free (you can see it above - displayed by v$asm_diskgroup view), I decided to take two disks out of +DATA and use them for +FRA.
The plan is to:
- Instruct ASM to not store more data on DATA_0002 and DATA_0003.
- Move all existing data from DATA_0002 and DATA_0003 to the other two disks.
- Remove DATA_0002 and DATA_0003 from +DATA diskgroup.
To accomplish this mission, I need to reconnect to ASM instance (in my case it is ORACLE_SID=+ASM1) as a privileged user:
$ echo $ORACLE_SID
$ sqlplus / as sysasm
SQL*Plus: Release 22.214.171.124.0 Production on Sat Dec 7 21:44:18 2013
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to: Oracle Database 12c Enterprise Edition Release 126.96.36.199.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
Now, I request ASM to move all data from DATA_0002 and DATA_0003 to other disks in +DATA group and remove those them from the group.
SQL> alter diskgroup DATA drop disk DATA_0002, DATA_0003;
alter diskgroup <name> drop disk command also allows specifying a speed of the operation -
alter diskgroup <name> drop disk <disks names> rebalance power <speed number>. The speed number is a number from 0 to 11 where 0 stops rebalancing and 11 means â€śfull speedâ€ť. If not specified a value from ASM_POWER_LIMIT initialization parameter is used.
The operation is heavy and may take some time depending on disks speed, workload, speed number used and amount of data to be moved. I monitor a progress by querying v$asm_operation view:
SQL> select group_number, operation, state, est_minutes
GROUP_NUMBER OPERA STAT EST_MINUTES
------------ ----- ---- -----------
1 REBAL RUN 2
1 REBAL WAIT 0
Once the query stops return REBAL rows I confirm completion of dropping the disks by quering v$asm_disk view:
select group_number, disk_number, name, total_mb, free_mb, path, header_status
HEADER_STATUS is FORMER which means that the disks were properly deleted from the diskgroup. You can also notice GROUP_NUMBER=0 so they no longer belongs to +DATA.
The current state can be presented on a chart like below: