If the uniform-sized extents are sized so that the initial load will have to allocate 50 or 100 or 400 extents, how much "processing overhead" do you think that dictionary-managed extent allocation operation will really consume, especially if the search of FET$ within those operations is made simpler by uniform-sized extents throughout the tablespace? Quite insignificant. Please measure it sometime...
This opposed to the wasted effort by DBAs/developers in attempting to calculate the "correct sized initial extent" for each table, plus the wasted processing in searching the FET$ table when the tablespace inevitably becomes "fragmented" due to non-uniform extent sizes, not to mention the time wasted by sales charlatans selling the latest "defragmentation" tool. I'm always struck by the way such "tablespace defragmentation" utilities resemble "hangover remedies" that include large amounts of alcohol... :-) Yeah, it makes you feel good -- for a couple more hours. Then... The concept of extents was devised to introduce the ability to adapt to long-term growth in space management. It is a tool to be used wisely, not a nuisance to be overcome. Following the train of thought of "one extent good, many extents bad" is simply wrong and a slippery slope to frustration... Wise use involves uniform-sized extents when possible, or at least a small number of extent sizes which are multiples of one another, as a second-best. The "locally-managed tablespace" mechanism shows both of those best practices encapsulated. The mechanism introduced in Oracle8 v8.0 of the MINIMUM EXTENT clause for the CREATE/ALTER TABLESPACE command with dictionary-managed tablespaces represents an earlier attempt at the same set of best practices... ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, May 28, 2002 2:01 PM > Rachel Carmichael wrote: > > > > > An example: Think of load a lot of data into a table, and then load > > > on a very limited basis. This tells me to create a large first > > >extent that everything can fit into. > > > > why? there is no benefit to that > > > > Rachel, > > No benefit when the data is loaded, but there is justification to it > if it avoids extent allocations during the load - at least for a > dictionary managed tablespace. > > -- > Regards, > > Stephane Faroult > Oriole Software > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Stephane Faroult > 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: Tim Gorman 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).
