Hi Dave, The duration of the rebalance operation differs between Oracle 10 and 11. 10g is slower and moves more data around. You van see this in v$asm_operation. And more importantly-you can't simply compare figures. What worked quickly for me doesn't mean it does for you. If you have a short maintenance window you might want to consider a standby database and a switchover operation. Simply create the standby database on the new storage array and dispose of the old primary after the switchover. The copying of LUNs between arrays is also a good way of doing it, but you might not have the software and/or license to do so. Hope this helps, Martin Martin Bach Oracle Certified Master 10g http://martincarstenbach.wordpress.com http://www.linkedin.com/in/martincarstenbach ----- Reply message ----- From: "Herring Dave - dherri" <Dave.Herring@xxxxxxxxxx> Date: Thu, Sep 9, 2010 16:18 Subject: ASM rebalance estimates To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx> Folks, Has anyone done any detailed investigations on how to estimate the time needed for a disk add and rebalance operation with ASM? Athough everything can be done "hot", our client (like probably most) requires us to perform the adding of any disks to ASM during our maintenance window and also asks for an estimate on the time involved. Their expectation has been that the time involved is only affected by the # of disks added. My contention is it's that plus the amount of data to be rebalanced, basically existing disk fullness or size of the diskgroup. Assuming everything stays consistent (power of 11 for the rebalance operation, load on the diskgroup, and each LUN or "disk" is physically made up of the same # and capacity of physical disks) here's what I believe to be true: * If you had 10 x 100 GB disks that were 80% full (or 800 GB of total data) and added 2 x 100 GB disks, the final set should be 12 x 100 GB disks with 800 GB of data balanced across them, so each would have 66.67 GB of data. To me that means, at a minimum, you'd have to move 10(80-66.67) = 133 GB of data. * Take the same scenario but this time the disks are 60% full (or 600 GB of total data), the final set should be 12 x 100 GB disks with 600 GB of data balanced across them, so each would have 50 GB of data. To me that means, at a minimum, you'd have to move 10(60-50) = 100 GB of data. Unfortunately I don't have any system to test this on and existing data is way off from my assumption on what's being done. Here's a listing of what I've collected: Size of # of Disks # of Used GB Est. GB GB "Total Elapsed Disks Added Existing "Total in to be Moved Work" - Server (Min.) Added (GB) Disks Work" Diskgroup Moved per Min Est. Work ---------------------------------------------------------------------------------------------------------- LnxA 412 9 118 51 1,763,618 5,747 862.05 2.09 880,879 LnxB 228 3 269 13 534,693 2,814 527.63 2.31 -5,595 LnxB 166 4 118 51 792,866 5,662 411.78 2.48 371,201 LnxC 202 4 118 51 1,199,042 5,820 423.27 2.10 765,611 LnxC 216 7 118 46 931,080 5,339 705.15 3.26 209,005 LnxD 98 3 118 11 332,504 1,218 261.00 2.66 65,240 LnxD 98 1 118 10 174,605 1,152 104.73 1.07 67,364 LnxE 76 3 118 11 321,145 1,176 252.00 3.32 63,097 "Total Work" refers to the column in V$ASM_OPERATION and the value listed is the last one displayed from this view before the operation completed. Has anyone done any research into this or recorded similar data? Thx. Dave Herring | DBA, Global Technology Services A c x i o m C o r p o r a t i o n 630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax 1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. | www.acxiom.com Service Desk: 888-243-4566, https://servicedesk.acxiom.com, GSCA@xxxxxxx *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. **************************************************************************** -- //www.freelists.org/webpage/oracle-l