Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: separate data/inidex

Re: separate data/inidex

From: Sean M <smckeown_at_earthlink.net>
Date: Tue, 23 Apr 2002 20:47:15 GMT
Message-ID: <3CC5C850.D8E616DA@earthlink.net>


Daniel Morgan wrote:
>
> I feel like a great deal of effort is being expended to drag out a simple
> general statement. But I definitely appreciate you sticking with me on this. I
> can't just tell students: "The books are all wrong, the experts are all wrong,
> and no one in the Oracle development community has a clue where to start."

Here's the problem Daniel: you want to replace the old adage "separate tables and indexes" with a new adage. Problem is, the old addage *was never right*, at least for the vast majority of real world, multi-user systems. So what makes you think there's a new one to replace it? If you're looking for general recommendations for distributing your I/O, the SAME paper is probably your best bet:

http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf

Basically, to use the toll booth analogy, you want to have as even a distribution of vehicles going through however many toll booths you have. If only one toll operator is allowed to service trucks, and another only motorcycles, and a third only sedans, etc., eventually one booth is going to back up. But if every booth is capable of servicing every vehicle at random, voila, even distribution. Now, *maybe*, for special applications and with very careful testing, you *might* manage to do better by manually allocating tablespaces to physical devices. But if you do manage to do better, it won't be very noticible, and you'll have spent far more time trying. Furthermore, the minute you need to add a new tablespace with new requirements, it's time to start all over again testing the manual process and moving datafiles around. No fun to manage.

Is SAME perfect? No. But if a general approach that works well for the majority of databases is what you're after, SAME is about as close as you're going to get.

Regards,
Sean Received on Tue Apr 23 2002 - 15:47:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US