Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Multiple Datafiles and performance?

Re: Multiple Datafiles and performance?

From: <>
Date: Thu, 07 Aug 2003 10:34:24 -0800
Message-ID: <>


For arguments sake, the I/O steps that you mention is for a single user. Assume thousands of users, in which case, everyone would be hitting the same disk volume. Whereas, if they were spread, the I/O would be spread across 2 different volumes.

Having said that, I dont recommend spreading them on different disk volumes. The goal should be spreading I/O evenly across all the available disk volumes. The S.A.M.E principle. Just for the heck of spreading the datafiles across disk volumes, I would not want the index datafile to be moved from a disk with 20% utilization to one with 90%.


                    Tim Gorman                                                                                     
                    <tim_at_sagelogix       To:     Multiple recipients of list ORACLE-L <>       
                    .com>                cc:                                                                       
                    Sent by:             Subject:     Re: Multiple Datafiles and  performance?                     
                    11:19 AM                                                                                       
                    Please respond                                                                                 
                    to ORACLE-L                                                                                    

I don't mean to be argumentative, but every time I see assertions like these, I suspect someone has been reading some rather discredited books...

So, my apologies in advance, but comments are inline below...

> In my experience, spreading datafiles across volumes (specially if you
> careful not to locate the a table's datafiles and its indexes datafiles
in the
> same drive) greatly increases performance.

The assertion that performance is enhanced by distributing datafiles containing tables and datafiles containing indexes to different volumes is a

Think about it.

Indexed access is a purely sequential activity from an I/O standpoint, putting aside the reality that a buffer cache exists. First, we access the root block of the index and read its contents in order to know where to perform the next I/O (i.e. a branch block). Then we read that branch block and read its contents in order to know where to perform the next I/O (i.e. a
leaf block). Then we read the leaf block and read its contents in order to know where to perform the next I/O (i.e. a block in a table). And so on...

Since we are performing sequential single-block I/O (hence the name of the wait event "db file sequential read"), how can separating datafiles containing tables from datafiles containing indexes matter to performance?

> As for the file size, I can not say because I have not tested it, but I
> it should have no real impact compared to splitting it. Reorganizing the
> database regularly is a better way to optimize performance.

And in what ways does "reorganizing the database regularly" improve performance?

To break the question down into more manageable pieces:

There are specific answers to these questions. For example, there are situations in which both tables and indexes can become "sparsely populated".
Tables become sparsely populated due to large-scale deletions. Indexes become sparsely populated due to monotonically-ascending data values inserted transactionally.

In these cases, how can you detect this condition? The package DBMS_SPACE has procedures that help for tables and the ANALYZE INDEX ... VALIDATE STRUCTURE command helps for indexes.

Does rebuilding a table or index that is not "sparsely populated" aid performance in any way? Quite frankly, no...

...well, there is one condition involving the "clustering factor" of an index where a rebuild of the table can help, but you'll end up hosing the "clustering factor" of other indexes. It is a case of favoring one index over another, and that is a decision that requires intimate knowledge of the
application's usage of the table and its indexes...

So, "reorganizing the database" on a regular basis is purely a waste of time. Regularly monitoring the database for "sparsely populated" tables and
indexes, and then determining if the condition is affecting performance of any important processes before rebuilding, will indeed help performance.

Sorry for the combative tone, but I hope this helps...


> -----Mensaje original-----
> De: Dave Phillips []
> Enviado el: miércoles, 06 de agosto de 2003 22:14
> Para: Multiple recipients of list ORACLE-L
> Asunto: Multiple Datafiles and performance?
> Oracle
> Win2k
> What is the consensus on datafile sizing and the impact/overhead
> multiple datafiles have on performance?
> For example, if I have one 2.5g datafile, and three 1g datafiles, and I
> need more space, would it be better to increase the size of the 1g to
> 2g or add another 1g datafile?.
> Is it better to keep them all uniform in size?
> I would think having multiple datafiles that could be spread across
> drive volumes would be beneficial, am I wrong? (Wouldn't be the first
> time :)
> David Phillips
> Support DBA
> Gasper Corp.
> BAARF member #30

Please see the official ORACLE-L FAQ:

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Aug 07 2003 - 13:34:24 CDT

Original text of this message