Re: SSDs and LUNs

On the other hand, LUN sizes of 1.5 TB are common. There is less administration to do on the Linux side and 1.5 TB of flash drive will outperform any rotational storage, simply because SSD is newer and better technology. What I am unclear is what do you need ASM and RAC in the cloud for? RAC requires application adjustment and if the cloud goes out, which has happened, all of your machines go out. A standby in a different zone would make much more sense.

Regards

On 10/19/2017 02:39 AM, Jonathan Lewis wrote:
> At some layer between Oracle and the silicon the various software components will have some queues. If there is a layer at which you have a single queue to each LUN you will have an I/O bottleneck when you've got lots of Oracle processes trying to read from just 2 (or 4) LUNs.
>
> I'm not an expert with stuff that far away from the Oracle software but I would be a little surprised if you got bad performance because you were configured as 40 LUNs, while I have seen bad performance from a system where the solid state SAN had been configured as just 2 LUNs (one for data, one for redo).
>
>
> Regards
> Jonathan Lewis
>
> ________________________________________
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Ram Raman <veeeraman_at_gmail.com>
> Sent: 19 October 2017 06:49:23
> To: ORACLE-L
> Subject: SSDs and LUNs
>
> 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.
>
> --
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

-- 
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217

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