Re: SSDs and LUNs

Worth a read

https://kevinclosson.net/2016/08/21/stop-constantly-adding-disks-to-your-asm-disk-groups-resize-your-asm-disks-on-all-flash-array-storage-adding-disks-is-really-the-y2k-way-heres-why/

On Thu, Oct 19, 2017 at 2:26 PM, Stefan Knecht <knecht.stefan_at_gmail.com> wrote:

> One thing that is to be considered is that you're "laying more eggs in a
> single basket". If you have one or two very large LUNs and anything goes
> wrong, you'll be restoring whatever was in that LUN. In your case, the
> entire 1.5TB.
>
> Another case to be made is that it is commonly accepted that you should be
> using same-sized disks within an ASM diskgroup. A good discussion on that
> is here: https://jarneil.wordpress.com/2008/04/10/keep-
> disks-in-your-diskgroup-the-same-size/ showing what can happen if you use
> different sized disks. If you're going by that you also have to consider
> what will happen when you later on want to expand the diskgroup. If you
> have 2x2TB LUNs, and you want to retain uniformly sized LUNs, you'll be
> adding another 2TB. Dividing them into smaller LUNs gives you more
> flexibility in the future.
>
> If they "claim" that 2 LUNs outperform 40 LUNs - assuming the same storage
> underneath and all, I'd love to see some numbers to back up that claim.
> From a read/write point of view, there is no difference. Oracle reads
> blocks, which are addressed directly. It doesn't matter in which LUN or how
> many LUNs they are in. This only has an effect if your reads or writes are
> hitting multiple LUNs which actually have different physical devices
> underneath. Since each device - regardless of technology - can supply a
> certain amount of sustained throughput and IOPS. But most modern storage
> systems will stripe every LUN across every available disk anyway (at least
> those I've been in contact recently) which kind of renders this a mute
> point.
>
> You also didn't mention how the LUNs will be presented to ASM? Are they
> mirrored on the storage tier? RAID 1? RAID 1-0? What ASM diskgroup
> redundancy is planned? If you're going for a normal redundancy diskgroup,
> where you leave ASM in charge of your data, you'd definitely want more than
> just 2 LUNs.
>
> <sarcasm>Perhaps they're just too lazy to create more LUNs? </sarcasm>
>
> Stefan
>
>
>
>
> On Thu, Oct 19, 2017 at 12:49 PM, Ram Raman <veeeraman_at_gmail.com> wrote:
>
>> We are moving one of the systems to vm. The consultants who have been
>> hired to do the implementation are recommending that we create just 2 or 4
>> 'LUNS' for data diskgroup for the db that is 3Tb in size which exhibits
>> hybrid IO. They are promising it is best rather than having 30 or 40 LUNs
>> since the new disks will all be SSDs.They are claiming that it will perform
>> better than having 40 'LUNs'. I still have the 'old way of thinking' when
>> it comes to IO. Can someone confirm one way or other, or point to any
>> paper. thanks.
>>
>> Ram.
>>
>> --
>>
>>
>>
>
>
> --
> //
> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
> Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
> | _at_zztat_oracle
>

-- 
Connor McDonald
===========================
blog:   connormcdonald.wordpress.com
twitter: _at_connor_mc_d

"If you are not living on the edge, you are taking up too much room."
- Jayne Howard

*Fine print: Views expressed here are my own and not necessarily that of my
employer*

--
http://www.freelists.org/webpage/oracle-l