RE: VLDB ASM & SAN Striping Question
- From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
- To: "'softice@xxxxxxxxx'" <softice@xxxxxxxxx>, "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 7 Jun 2012 08:00:15 -0500
Sve,
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Svetoslav Gyurov
Sent: Thursday, June 07, 2012 7:52 AM
To: oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
