Xref: alice comp.databases.oracle.server:69210 Path: alice!news-feed.fnsi.net!netnews.com!newshub.northeast.verio.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!jlcomp.demon.co.uk!not-for-mail From: "Jonathan Lewis" Newsgroups: comp.databases.oracle.server Subject: Re: ? on alter tablespace pctincrease Date: Sun, 10 Oct 1999 14:42:38 +0100 Message-ID: <939563167.22850.0.nnrp-07.9e984b29@news.demon.co.uk> References: <37fe0d8e@News.Destek.net> <37FDD0DB.3FBC@yahoo.com> <37fe360d@News.Destek.net> <38002E2C.61FB@yahoo.com> X-Trace: news.demon.co.uk 939563167 nnrp-07:22850 NO-IDENT jlcomp.demon.co.uk:158.152.75.41 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Lines: 34 And with Oracle 8.1, life is even easier, you just declare the tablespace to be locally managed with uniform size (suitably chosen) and forget the whole issue. -- Jonathan Lewis Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk Connor McDonald wrote in message <38002E2C.61FB@yahoo.com>... > >If you size your objects well - you DON'T need to coalesce free space. > >For example, lets say you size all tables in your tablespace to be >either 1m, 5m or 50m. As extents are freed up for either tables >shrinking or being dropped altogether, the probability of another object >being able to fit into the free space is quite good. > >Optimal is to have a tablespace for each size. Then you never have >holes that cannot be filled. Thus you may have tablespaces like: > >DATA_BIG default storage 1m >DATA_MEDIUM 5m >DATA_SMALL 50m > >you don't need to coalesce, you don't need to worry about fragmentation >because everything just slots neatly in to the gaps... > >Thats a lot of admin overhead resolved...! >