RE: Question on LUN Sizes for storage migration
Date: Wed, 21 May 2014 16:49:04 -0400
Message-ID: <035b01cf7536$1b5ae820$5210b860$_at_rsiz.com>
Good advice about developing a relationship with your storage team. Telling them WHY things matter and the information you have to give ASM should help the relationship.
Now, at the margin it is probably best to give ASM whole disk (or disk pairs or triplets if you have external redundancy). If you carve disks up and present them to ASM as different LUNs, then ASM does not have a way to understand that two or more LUNs actually reside on a single spindle.
You’ve given us no idea of the underlying number of spindles making up these LUNs. With recent storage densities the new ones could be fractional disks and the old 90’s could be 10 9 GB disks in a stripe. If that is the case and we’re talking spinning rust for all the devices, then your new LUNs will support far fewer I/O operations per second per GB of storage. Of course if the old bottleneck was the connection from the computer to the storage and the new LUNs are connected by a much faster interface.
Okay, long winded again. Without knowing the whole stack of i/o from computer memory to the persistent device before and after, a predictions for changes in behavior cannot be made.
The changing size of a LUN presented to ASM is probably the least of your worries. If someone carved up a 2 TB disk and presented it to you as 4 500GB LUNS, now I’d be really worried about that. You absolutely do need to know the components to tell ASM reasonable values for redundancy and recovery groups.
Good luck.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Kenny Payton
Sent: Wednesday, May 21, 2014 3:47 PM
To: ksmadduri_at_gmail.com
Cc: oracle Freelists
Subject: Re: Question on LUN Sizes for storage migration
The size of the lun is not as important as the IO characteristics of it. The performance difference of the two luns could be identical or drastically different, it really depends on a lot of variables.
My recommendation is to attempt to build the best relationship you can with your Storage Team and understand the configurations to the best of your ability. While doing this also share the database workloads and behaviors with them. Together you have the best chance of creating a sustainable and performant environment not to mention a relationship that will pay you back 10x over time.
On Wed, May 21, 2014 at 6:13 AM, Kumar Madduri <ksmadduri_at_gmail.com> wrote:
We were originally given 90 GB LUNS.
As part of storage migration to another vendor, we are being provisioned with 500 GB LUNS.
From a migration point of view, is it ok to move the data from 90 GB LUNS ton 500 GB LUNS. We would have 20 90 GB LUNS (old storage) and 4 500 GB LUNS (new storage)
alter diskgroup DATA
drop disk
'/dev/old-lun1 -90-gb', '/dev/old-lun2-90-gb' ...., '/dev/old-lun20-90-gb'
add disk
‘/dev/new-lun1-500gb’, ‘/dev/new-lun2-500gb, ’, ‘/dev/new-lun3-500gb, ’, ‘/dev/new-lun4-500gb, ’ ;
Concern is, would it be better to stick to 90 G LUNS on new storage as well or move to 500 GB LUNS as above (as part of migration). Our concern is would it slow down migration if we alter the lun sizes as part of migration process.
Our Unix/Storage admin prefers the 500G LUN because they say it will reduce the time for reboot (when required) if we have fewer number of LUNS.
Thanks again for time.
- Kumar
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 21 2014 - 22:49:04 CEST