There are three (3) types of LMTs (yes, three!) UNIFORM Extent sizes Every extent created in the tablespace will be the same size, no matter the storage parameters specified.
AUTOALLOCATE (System managed) The system will decide the next extent size at creation. This is based on a large number of things. (I think the phase of the moon and the number of sun-spots on 03-03-1942 are included in this calculation) The min extent size is 64K USER Allocated This is only available for tablespaces that were converted from dictionary managed tablespaces. As it would seem, the user determines the space allocation -- the space allocation is the same as for dictionary managed tablespaces. The benefit is that bitmaps rather than freelists are used to identify free space. With UNIFORM, you can tell exactly how many allocations will be required to fill up the tablespace. (freespace / extent-size = #allocs) With User Allocated use the same logic as you would for dictionary managed tablespaces. With Auto-Allocated extents, um. You don't know what the next extent size will be. Kevin -----Original Message----- Sent: Monday, March 10, 2003 12:04 PM To: Multiple recipients of list ORACLE-L I admit to being sleep-deprived but I don't see how there is a difference between monitoring dictionary managed and locally managed tablespaces when you are talking about the inability to allocate another extent. It seems relatively simple to me: check the size of the next extent that will be allocated (this can be calculated, regardless of auto allocate, uniform or dictionary managed next and pctincrease). Check to see if there is that much space available in the tablespace. If you REALLY want to be paranoid, do this as if you expect EVERY table and index in the tablespace to extend at the same time. If remaining unallocated space is greater than the next extent allocation you calculate, you have enough space. If it is not, you have to add a datafile or extend the existing one. Or am I missing something? Rachel --- "Jamadagni, Rajendra" <[EMAIL PROTECTED]> wrote: > I have been reading some docs on free space etc., but I have not yet > found > any conclusive document on how to monitors tables/indexes in LMT > environment > so that we could *predict* when a segment would not be able to > allocated > extent. > > Basically we want to monitor, when we needs to add more space to a > tablespace, at-least 1 day before we get error messages. Devl team > doesn't > always tell us before dataload (it happens, and now they have been > warned). > > I believe this is little bit complex compared to dictionary managed > tablespaces, as (in auto allocate mode), there is no fixed published > formula > for next extent ... > > Any ideas? TIA > Raj > ------------------------------------------------------------- > Rajendra dot Jamadagni at espn dot com > Any views expressed here are strictly personal. > QOTD: Any clod can have facts, having an opinion is an art !! > > > ********************************************************************This > e-mail message is confidential, intended only for the named > recipient(s) above and may contain information that is privileged, > attorney work product or exempt from disclosure under applicable law. > If you have received this message in error, or are not the named > recipient(s), please immediately notify corporate MIS at (860) > 766-2000 and delete this e-mail message from your computer, Thank > you.*********************************************************************2 > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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.net -- Author: Toepke, Kevin M INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
