RE: RAC/ASM Help
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <shivaswamykr@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 20 Oct 2006 11:34:45 -0400
Are your disks all the same speed? (It is not advisable to mix different
speeds in a disk group, even if you otherwise fit the profile to go with the
simplest organization, SAME).
Do you have a single EMC array cache, or can your array cache be divided
amongst sets of independently operating i/o paths from the computer memory
down to the spinning rust?
Do you have any solid state disks (SSD) that meet your robustness
qualifications for database storage?
Do you need to minimize the affect of high activity of one of your databases
on other databases?
Do you have heavily i/o intensive batch jobs that have a potential to stream
(which may be interpreted by ASM as a hot spot when in fact it is maximum
throughput with minimized seek overhead)?
Can you figure out how much money in configuration overhead it is worth it
to you to spend to implement a more complex scheme if you need to
accommodate these (and probably I'm leaving some out) *POTENTIAL* benefits
over the cost of implementing and maintaining SAME?
Let's consider this very briefly in very vague terms. Let's say you'll use
150 of your disks for "live data" and 50 of your disks for "FRA". Let's say
all your disks are the same speed and you've got no SSD and you've got a
single EMC array cache and you don't have any batch jobs with a potential to
significantly stream i/o. Then you're pretty much down to just the isolation
argument. If database "A" and database "B" have differing workshift
requirements, that is to say, they are busy at different times, then going
SAME you get the benefit of more disks simultaneously serving the "busy"
database without much downside. If database "A" and database "B" overlap in
when they are busy, then there is potential for the activity on "A" to
affect whether you can maintain your service level requirements on "B". If
that is important to you, then you probably want to build more diskgroups,
understanding that fewer total potential i/os per second will be available
to "A" or "B" individually. If you do this, be particularly careful to
understand what the i/o path is down to the actual spinning rust and that
you do not compromise the i/o path to groups for "A" when you build groups
for "B", and the reverse. (If you're going to do that, you might as well
settle for SAME in the first place.) If you're mostly all in array cache
most all the time none of this is too important, except possibly for
streamable batch jobs. I've heard that a book named something like "SANE
SAN" is pretty good on this topic, and Jonathan Lewis has had some
interesting things to say about the other guy's database activity trashing
your throughput. There is a *lot* of valuable truly expert opinion out there
on this subject, some of which appears to be in conflict with other advice,
when in fact usually the folks are talking about substantially different
environments when they disagree. Deeply understanding the operational
profile of your existing databases that will be sharing the i/o farm is your
best preparation (short of an actual full load simulation test) for deciding
which advice best applies to your situation.
Good luck and best wishes.
mwf
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Shivaswamy Raghunath
Sent: Friday, October 20, 2006 10:41 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RAC/ASM Help
Hello.
We are planning to go for RAC for our DSS Type(Decision Support System)
databases with ASM. I want some input from you as far as ASM configuration
is concerned.
How many diskgroups are common to have in a database? I know Oracle prefers
two - one for data & one for FRA(Flash Recovery Area). We have about 200
disks on EMC currently. So, external redundency if we continue with EMC
Raid. Then, are we to put all the disks on one diskgroup?[ We currently have
about 65 Volume Groups]. While I do not have the disk size exactly for each
of them, I am sure they are of different properties - size, speed etc. Am I
to put all of them into one diskgroup? Any changes to disk group - if I have
one disk group - will affect whole of the databases, because of rebalancing,
will it not? Am I not better served in having more than one diskgroup?
How many disk groups do you have in your implementation? Can you tell me the
size of the database? Have you gone for external redundancy? Any issues
there?
Our main database will be about 3.5 TB in size.
TIA,
Shiva
Other related posts:
