Path: news.easynews.com!newsfeed1.easynews.com!newsfeed2.easynews.com!easynews.com!easynews!newsfeed.news2me.com!news2.euro.net!news2.euro.net!newshub1.home.nl!home.nl!not-for-mail From: Frank Newsgroups: comp.databases.oracle.server Subject: Re: Tutorial about STORAGE parameters Date: Mon, 03 Mar 2003 20:22:04 +0100 Organization: @Home Benelux Lines: 74 Message-ID: <3E63AB5C.7060209@netscape.net> References: <3E60B5D0.2080600@netscape.net> NNTP-Posting-Host: cc28855-a.hnglo1.ov.home.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news1.tilbu1.nb.home.nl 1046719295 24699 217.121.193.81 (3 Mar 2003 19:21:35 GMT) X-Complaints-To: abuse@home.nl NNTP-Posting-Date: Mon, 3 Mar 2003 19:21:35 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en Xref: newsfeed1.easynews.com comp.databases.oracle.server:178293 X-Received-Date: Mon, 03 Mar 2003 12:21:34 MST (news.easynews.com) Howard J. Rogers wrote: > On Sat, 01 Mar 2003 14:29:52 +0100, Frank wrote: > > >>Howard J. Rogers wrote: >> >>>An excellent suggesiton from Norman, but I would want to qualify that >>>advice by saying that the extent sizes proposed in the paper he >>>references are distinctly odd, and you'd be much better off creating >>>extent sizes following the same sort of algorithm that Oracle itself >>>uses with auto-allocated locally managed tablespaces... namely, 64K >>>etxents, 1MB extents, 8MB and 64MB for the really big tables. >>> >>>I can't see any possible need for any other extent sizes (though I have >>>occasionally been known to ignore my own advice and slot a 512K extent >>>tablespace in between the 64K and 1M ones). >>> >>>Regards >>>HJR >> > > >>But there is a logical relation between the sizes: they all are a factor >>32 apart; your 64k - 1M - 8M - 64M is odd in that respect: 16 - 8 - 8 - >>8. > > > Not my sizes: it's what autoallocate does! > > >>Following the rule, described in the article mentioned would result in >>64k/2M/64M. For most of the databases, the 64k and 2M will be enough; >>the 64M tablespace would harbour segments over 2GB. >> >>The document suggests extent sizes of 128k - 4M - 128M for 8.0 onwards, >>fail to see what is odd about that. > > > "Odd", meaning that 128K is going to be rather large for many segments. > Obviously, you have to start somewhere, but I like 64K because it's not > *too* big for the small segments, but is big enough to not cause huge > numbers of extents for moderately large segments, either. > > Likewise the leap from 4M to 128M is a big one. 1M to 8M is (as you point > out) much smaller... and the finer granularity means less wasted space for > particular segments. > > The issue is that ultimately, any such approach is going to be a 'one size > fits all' policy, with a compromise to be struck between ease of > configuration and excessive space wastage for those segments where the > 'one size' isn't quite appropriate. I like the autoallocate sizes because > I think they strike the right balance. I don't like the paper's proposed > sizes because I think they over-do it, and result in space wastage worse > than any degree of fragmentation. > > But it's not critical, I guess. > > Regards > HJR > > > > >>Regards, Frank van Bortel > Agree -not critical. And the document reasons why the sizing is chosen as it is. Otoh, I did not realize the exent sizing you quoted was LMT. Someone within Oracle must have thought otherwise - or did not read the original article ;-) -- Regards, Frank van Bortel