Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: How are extents allocated in a multi-datafile tablespace

RE: How are extents allocated in a multi-datafile tablespace

From: yong huang <>
Date: Fri, 22 Dec 2000 08:38:34 -0800 (PST)
Message-Id: <>

Hi, Chuck,

I found this from my message archive. I have no additional comments.

Hi Jonathan,

I believe that round robin extent allocation was at first only used for parallel
segment creation operations, but was implemented for dynamic extension in 7.3. However, from some testing I did at the time, it seemed that Oracle would reuse an extent of the correct size in any datafile rather than split an extent in the
"next" datafile.

@   Regards,
@   Steve Adams
@   Going to OpenWorld?
@   Catch the Ixora performance tuning seminar too!
@   See for details.

-----Original Message-----
From: "Jonathan Lewis" <>

I've just run a few tests of this with locally managed tablespaces, usng the 'alter table allocate extent' command, and the algorithm certainly seems to be a round-robin. I vaguely recall seeing something in the manuals to this effect too, but can't find it at present (isn't that always the way).

There is no visible clue in the recursive activity to prove that Oracle is doing a round-robin, other than the fact that Oracle loads the file$ details for all the files in the tablespace as the first step of allocating the extent. Presumably the actual decision code is hidden in dictionary cache processing of dc_used_extents.


Jonathan Lewis
Yet another Oracle-related web site:

Jonathan Lewis wrote in message

>It's just occurred to me that the apparent round-robin
>may be a side-effect of the way space management
>works on dictionary managed tablespaces and not
>a planned feature. I'm going to have a proper look at
>it, and will get back to you.
>Jonathan Lewis
__________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products.
Received on Fri Dec 22 2000 - 10:38:34 CST

Original text of this message