I would content that the moment the extent size is
greater than SSTIOMAX (or whatever the OS can
service), then you won't see any benefit from fewer
extents even on data warehouse - the only exception I
can think is if you were lucky enough to be the only
user on a particular disk/volume during the run of
your query - which I think would be extremely rare.  

This is not to say that reorgs are not worthwhile -
I've seen warehouses triple in performance simply by
"pseudo-clustering" the data during reload to get some
affinity with the typical queries run against it.

To respond to the previous post - locally managed
tablespaces are a wonderful way of migrating all your
segments down to the "front" of a tablespace - it just
happens automagically with an "alter table move"

hth
connor

 --- Rachel Carmichael <[EMAIL PROTECTED]> wrote:
> something along those lines...
> 
> as with everything there is no real black or white
> on this... but
> transactional systems that do a lot of small
> (non-sequential) reads you
> are better off with lots of extents while data
> warehouses are often
> better off with fewer extents as the reads tend to
> be sequential or
> full table scans so you would want more of the data
> together
> 
> as for those little bitty extents -- you mean you
> aren't using
> tablespaces with a single extent size so you don't
> have to worry about
> them?
> 
> 
> --- [EMAIL PROTECTED] wrote:
> > Back in the V6 days it was a desired
> characteristic to have every
> > thing in the
> > first extent of an object for performance reasons.
>  Thankfully those
> > days are
> > gone and it really does not matter how many
> extents there are. 
> > Rachel has a
> > presentation on Oracle Myths where she actually
> portrays having
> > multiple extents
> > as a good thing from an IO perspective (Rachel,
> correct me if I got
> > this wrong).
> >  Although I can't give you exact examples, take a
> look and 
> > v$filestat.  I've found that tablespaces where
> there are more than
> > one extent in
> > the objects have a lower average io wait time that
> those where
> > everything is in
> > the first extent.
> > 
> > The only real good reason I have found for
> re-organizing a tablespace
> > is to get
> > all of the used extents at one end and all of the
> free extents (you
> > know those
> > little bitty ones that individually aren't worth
> the trouble, but
> > together!!) at
> > the other end.
> > 
> > Dick Goulet
> > ____________________Reply
> Separator____________________
> > Author: Christopher Spence <[EMAIL PROTECTED]>
> > Date:       10/2/2001 7:55 AM
> > 
> > That is completely a myth.  There is no notable
> performance different
> > with a
> > table with 10,000 extents and one with 1. 
> > 
> > The only problem is when it comes to the bitmaps
> when dealing with
> > LMT and
> > cluster when dealing with dictionary managed. 
> When you query the
> > extent
> > views, or do space management type processes.
> > 
> > "Do not criticize someone until you walked a mile
> in their shoes,
> > that way
> > when you criticize them, you are a mile a way and
> have their shoes."
> > 
> > Christopher R. Spence 
> > Oracle DBA
> > Phone: (978) 322-5744
> > Fax:    (707) 885-2275
> > 
> > Fuelspot
> > 73 Princeton Street
> > North, Chelmsford 01863
> >  
> > 
> > 
> > -----Original Message-----
> > Sent: Monday, October 01, 2001 7:15 PM
> > To: Multiple recipients of list ORACLE-L
> > 
> > May be it is good practice to keep number of
> extents to be less than
> > 50, no
> > matter what the size of extent.
> > 
> > 
> > 
> > -----Original Message-----
> > Sent: Monday, October 01, 2001 3:35 PM
> > To: Multiple recipients of list ORACLE-L
> > 
> > 
> > Hello,
> > 
> > I'll do an reorganization of a database (about 140
> gigs). Some people
> > say
> > that it'd be good to use 128K, 4M and 128M
> extents. I saw somewhere
> > it'd be
> > 160K, 4M and 160M. Which size do you advice me ? I
> have also many
> > small
> > indexes (less than 16K).
> > 
> > Regards,
> > 
> > Thanh-truc Nguyen
> > 
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> > -- 
> > Author: Thanh-truc Nguyen
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services    -- (858) 538-5051 
> FAX: (858) 538-5051
> > San Diego, California        -- Public Internet
> access / Mailing
> > Lists
> >
>
--------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (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).
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> > -- 
> > Author: Wong, Bing
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services    -- (858) 538-5051 
> FAX: (858) 538-5051
> > San Diego, California        -- Public Internet
> access / Mailing
> > Lists
> >
>
--------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (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).
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> > -- 
> > Author: Christopher Spence
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services    -- (858) 538-5051 
> FAX: (858) 538-5051
> > San Diego, California        -- Public Internet
> access / Mailing
> > Lists
> >
>
--------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (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).
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> 
=== message truncated === 

=====
Connor McDonald
http://www.oracledba.co.uk (mirrored at 
http://www.oradba.freeserve.co.uk)

"Some days you're the pigeon, some days you're the statue"

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: =?iso-8859-1?q?Connor=20McDonald?=
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).

Reply via email to