RE: VLDB ASM & SAN Striping Question

Thank you for that information. Very insightful. Mainly I'm planning for the future. Thinking about VLDBs and how to manage disks layouts based on what the Oracle docs had to say about the physical layout. Clearly the EVA series doesn't seem to allow this fine grained approach which is good to know but it's not really my focus as our databases are only approaching several hundred gigabytes per instance. But I wanted the information in case I happen to move into a shop where the databases are much, much larger.

Chris Taylor

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Svetoslav Gyurov Sent: Thursday, June 07, 2012 7:52 AM
To: oracle-l_at_freelists.org
Subject: Re: VLDB ASM & SAN Striping Question

Hi Chris,

Just to share my experience, sorry, but it's particularly for EVA as I have most experience with. For several years now I've never experienced performances issues with EVA and I'm very happy so far. Yes, HP recommends putting all the drives in one disk group, by doing so you're supposed to get best performance, which will scale if you add more disk drives. Yes, creating a disk group in EVA will span across all disk drives and LUNs in this disk group will span across all disk drives within the disk group. The only few times I saw disks divided into different disk groups was because of different disk kind (FC, FATA, SSD) and/or FC disks with different rotation speed (10k, 15k). Just to know - disk group redundancy has two options - single protection or double protection. Meaning that you won't loose any data in case of single disk failure or for double protection failure of two disks failures. There are no spares here, but the space for protection is reserved within the disk group.

Now, there are two problems with EVA - controller cache is one for all disk groups i.e. disk group doing more operations will occupy more of the cache space. Second there is no I/O prioritization, neither per disk group, nor per LUN.

A problem I had with EVA4400 was that customer had two disk groups - one with 30 FC drives and one with 50 FATA drives. What was happening was that LUNs on the FATA drives saturated the cache of the controller. As an immediate result we saw that log_file_sync of database running on the FC disks increased by times of 10x or more and this wasn't even in the business hours. The only solution for this was to separate the LUNs of FATA drives on one controller and LUNs of FC drives to the other one.

So particularity for EVA I don't see any real benefit of spiting disks (one of a kind) in more than one disk group. Again, it depends, without I/O prioritization one could prefer to separate critical database in different disk group. The only configuration you could take care of is to divide LUNs equally on both controllers (which EVA is doing by default).

Usually I create at least two LUNs with proper size in VRAID5 and build on top of them ASM disk group with external redundancy.

Here are few good papers for reference:

http://h71028.www7.hp.com/enterprise/downloads/4AA0-9728ENW_ASM_EVA_Best_Practices_White_Paper_final%20121806.pdf
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-6194ENW.pdf
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-5658ENW.pdf

Regards,
Sve
--

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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Jun 07 2012 - 08:00:15 CDT