sys adm / oracle database / p2000 array

[Charles McCary]

Group,

Config:

rx6600 with direct fiber attached P2000 G3.

Running oracle db.

Questions:

Different VDISKS (with a single volume) for data, indexes, archive logs?

OR

One VDISK with multiple volumes?

OR

Multiple VDISKs with multiple volumes?

I want to make sure I'm separating data and indexes from redo-logs while at the same time maximizing performance and balancing workload over controllers.

[TwoProc]

Charles, the more separation of physical areas the better. Multi-vdisks, multi-volumes, across multi physical disks. Try not to use R5. If u must, try NOT to use it for redo logs, temp, archive logs.
Interleave your redo logs across two different disks, and put your archive logs on a third.
Of course, very large arrays across lots of disks, with lots of write through cache ram on the front of the box diminish these requirements a great deal. Very large Oracle memory spaces for buffer caches diminish some of these requirements as well. What is "very large", well it's the amount where your total I/O very tiny and well below the average conceptual deliverables of what your storage environment can do. The fact is, RAM in the server is the cheapest "I/O storage system" you can buy, if you get what I'm saying. In other words, caching a lot of reads and writes can effectively mask lots of underlying I/O non-optimal settings. Very much like using caulk and paint to make your house look square and perfect, when we know all those molding corners aren't even nearly considered perfect, it's OK, if it appears that they are. :-)

[Zygmunt Krawczyk]

I recommend reading the doc

HP StorageWorks P2000 G3 Modular Smart Array System with Oracle

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-9008ENW.pdf

[Hein van den Heuvel]

I was eager to check out the "p2000 + Oracle " document Zygmunt Krawczyk pointed to, but now I recall I saw it before and there was nothing much salient in there.
I like the explicit data versus redolog separation it mentions as I also believe those access patterns are sufficiently different to warrant attention/spread.

I no longer believe in separating data versus index.
That was great 20 years ago when we did not have smart controllers with big (write-back) caches to spread the load.
These days I am much more in the 'SAME' camp (Stripe And Mirror Everything ... google).
Manual tweaks/placement will create unbalanced IO load and missed performance.
For some time I still liked spreading data and index with single vdisk and multiple volumes to allow me to use system tools to see how much IO each flavor generated. But Oracle will happily tell me, and does it really matter if they share one big pool? What are you going to to when you see index has 3x more IO then data or visa versa?
It's not going to drive any change is it now?

Law of the big numbers... the more the merrier.

Hope this helps some,
Hein

[Charles McCary]

I read that doc as well and didn't find it particularly helpful.

When you use SAME, I'm assuming you're using it at the LVM level.

So, here's a potential solution:

1) Create LUNs for redo/undo/archive logs, mirrored ( RAID 10) at the array.

2) Create LUNs for data/index. These can be RAID 5 (improvements in write cache considered here).

3) For all LUNs stripe and mirror at the LVOM level (isn't the mirroring redundant here?).

Please give me your thoughts on this proposal.

One thing I dislike about striping at the LVM level is the admin hassles down the road with adding new disks, etc.


thanks,

C

[Charles McCary]

questions answered.