Multiple extents a good thing? YES! I'm *depending* on many multiple extents of an interMedia index segment (the DR$<>$I segment) to distribute I/O for full text indexing and queries. I plan to distribute the datafiles of the tablespace holding the DR$<>$I segment across multiple drives and set the uniform extent size to 1MB. Since Oracle8i distributes new extents for a table or index in a round-robin fashion, I'll get even distribution of that big token table across several spindles. (...and with a couple gig more RAM on a new Win2k box we're getting, I'll be able to cache all 900MB of the DR$<>$X index - YAY!) 8^)
BTW, the largest of our out-of-line CLOB segments have nearly 30,000 extents (1MB per extent) with no performance problems at all. However, I am going to implement 100MB extents for those CLOB segments on the new box, to keep the LMT bitmaps within an 8KB block. Jack -------------------------------- Jack C. Applewhite Database Administrator/Developer OCP Oracle8 DBA iNetProfit, Inc. Austin, Texas www.iNetProfit.com [EMAIL PROTECTED] (512)327-9068 -----Original Message----- [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 12:15 PM To: Multiple recipients of list ORACLE-L 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 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack C. Applewhite 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).
