# of extents has little if anything to do with performance - you could
construct an extreme case where each extent has a couple of blocks and
show that a scan was slower due to the overhead of having to look up
the extent map - but assuming you are'nt doing something so extreme
there should be no relationship between performance of DML and/or
queries and # of extents.
Sylvain Leclerc <SLeclerc_at_magrit.com> wrote in message news:<CCD755725CEABC448827E1E1C16E6833019869_at_conceptum04.magrit.int>...
> This is the best I have found
>
> http://www.ixora.com.au/tips/creation/extents.htm
>
> Sylvain Leclerc, DBA
> Conceptum Informatique
> sleclerc_at_magrit.com
>
> -----Original Message-----
> From: Reza [mailto:reza_at_digital-dispatch.co.uk]
> Posted At: Thursday, September 06, 2001 6:18 AM
> Posted To: server
> Conversation: Any Final Verdict on Nr. of Extents?
> Subject: Any Final Verdict on Nr. of Extents?
>
>
> Hi guys
> I've been having a hot debate with our new say DBAs, on effect of Number
> extents in an object like a table or index on performance.
> Basically I didnot agree to take a 7x24 system down for 6 hours to just
> reduce the number of extents on few huge tables and their indexes.
> I would personally believed few years ago that lower number of extents
> will
> be better performance and even remember arguing this with some Oracle
> Tutors
> in their lectures. Since then I have somehow revised my view due to
> working
> with few production databases, and also hearing more from other DBAs in
> favor of ineffectiveness of Nr. of extents in Performance.
>
> Anyway I would appreciate if anyone could direct me to a definitive
> article
> or somehow share their view on this so I can supprt my argument better
> or at
> list to revise it again.
> I think somehow fragmentation problem might come to this argument as
> well,
> if the extents are not contiguse in the Objects table space. Any view on
> this aspect.
>
> May thanks for any help or feedback.
> Best Regards
> Reza Oskouie
Received on Thu Sep 06 2001 - 17:08:39 CDT
