RE: RAC/ASM Help

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Shivaswamy Raghunath
Sent: Friday, October 20, 2006 10:41 AM
To: oracle-l_at_freelists.org
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

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