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@xxxxxxxxx>
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@xxxxxxxxx> 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
| @zztat_oracle
