Balancing ASM disks in one command – the benefits
Posted by John Hallas on June 5, 2012
As a response to my previous post about adding and dropping ASM disks with one command Emre Baransel asked a question as to whether it was more efficient or not to do it as one or two commands. It was easier to add a second post complete with screen shots rather than just a simple reply.
My test system was a 3.5Tb database spread across 10 512Gb luns.
The first choice was to add and drop in a single command one command
alter diskgroup data add disk '/dev/oracle_3par/rdisk5008' drop disk 'DATA_0000' rebalance power 5; GROUP_NUMBER OPERA STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ------------ ----- -------- ---------- ---------- ---------- ---------- ---------- ----------- -------------------------------------------- 1 REBAL RUN 5 5 6882 419874 20621 20 GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- -------------------------------------------- 1 REBAL RUN 5 5 10064 419880 24541 17
This was at power level 5 and the actual work (number of allocation_units to be moved) was ~420k.
Note the throughput on the HBA adapters generated by 5 asm_arb+ASM1 processes
Changing the power level to 9 causes another 4 arb processes to start and the HBA throughput increases significantly (this was a test system on a Bank Holiday, not to be recommended on a production system)
The second method was to drop and add in separate commands, all with the same power level of 5
alter diskgroup data add disk '/dev/oracle_3par/rdisk5008' rebalance power 5; GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- -------------------------------------------- 1 REBAL RUN 5 5 3503 376381 10219 35 alter diskgroup data drop disk 'DATA_0000' rebalance power 5; GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- -------------------------------------------- 1 REBAL RUN 5 5 196638 378433 19355 9
As can be seen, the overall work to be done is ~750K allocation units to be moved around which is almost double the original workload.
Narendra said
John,
Thanks for these 2 posts (claim and evidence). Documentation does make a reference to this here but could not find the WHY part there