Re: LOCALLY MANAGED EXTENT PERFORMANCE
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: rjamya@xxxxxxxxx
- Date: Tue, 26 Apr 2005 13:50:37 +0100
On 4/25/05, rjamya <rjamya@xxxxxxxxx> wrote:
> Ibarhim,
> No your query will not work. Extents sizes in autoallocate are based on =
an
> algorithm, search the archive of oracle-l (at fatcity.com<http://fatcity.=
com>or
> orafaq.net <http://orafaq.net>) if you prefer. AFAIK the algorithm change=
s
> if you use non-standard initial extent as well. Since it is already in
> archives I'll not search my emails to paste it here.
The only trouble is that there is no such algorithm. Jonathan Lewis
posted this correction to a poster who made reference to the fact that
the algorithm wasn't documented.
"Bottom line - there is no 'algorithm', only a policy,
and the general directives seems to be:
use space close to the start of the file
don't generate large numbers of extents if you don't need to
Use extents in the list 64K, 1M, 8M, 64M, 256M
(I'm not sure about that 256MB - I think I tested it once) "=20
I remember this well because it was me being corrected. Now Jonathan
*may* have changed his position on this in the last few years, and I
don't think I have ever seen, or seen reference to 256M being used -
perhaps they have some at SLAC (should have enough data there), but
the general point that the 'published' next extent sizes don't
actually hold in the real world. This is in fact one of the cases
where single user scripts don't even show Oracle Behaviour let alone
Oracle performance.
Cheers
--=20
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
