RE: Why "Separating Data and Indexes improves performance" is a myth?
- From: <Paula_Stankus@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 23 Apr 2004 15:54:34 -0400
Better yet: Do an automated stress-test before release into production =
and understand the characteristics of the database so you can spread out =
the I/O in a way that makes sense before you have to.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Nuno Souto
Sent: Friday, April 23, 2004 3:23 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Why "Separating Data and Indexes improves performance" is a
myth?
----- Original Message -----=20
From: <Paula_Stankus@xxxxxxxxxxxxxxx>
> So in laying out disks for a new database - perhaps the only thing =
worth =3D
> separate out is the redo based on I/O contention - right? =3D20
>
Not really. If you have a "mostly-read" database, why separate the redo
if you rarely write to it? Waste of time and disk.
I guess the real issue in this whole argument of separate I/O
is that there is no such thing as a silver-bullet approach to
splitting files in an Oracle database. The nature of EACH SPECIFIC
case dictates what should be spread across devices and what should not.
To try and find a one-size fits all rule is just condemned to failure.
The problem is: Find out if you have I/O contention.
The solution is: IF you have I/O contention, find out where
and spread THAT load.
If that means you have to allocate more disk to the system
tablespace, or to the redo, or to a single table, or to a group of
indexes, or whatever is your problem area, then so be it.
Trying to make a rule of thumb out of something that has got
no hands is really hard... ;)
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxxxxx
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
