Re: LMT advice

I like uniform and the 1M size for uniform too.

With autoallocate with LMT, is there an easy way to see if extents will be able to get their next size? Or , is this handled - just max out the datafile ?

-- 
"Richard Foote" <richard.foote_at_bigpond.com> wrote in message
news:gghdb.126259$bo1.14654_at_news-server.bigpond.net.au...


> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message

> news:3f74dd7c$0$6610$afc38c87_at_news.optusnet.com.au...

> >

> > None whatsoever, except that you have to decide on what the uniform size

> > should be. I tend to recommend 64K, 1M, 8M and 64M, but 'How to stop

> > worrying about fragmentation and start living', or whatever that

 Metalink


> > whitepaper was called, decided some other sizes would be good. Who can

 tell


> > what sizes are good and what aren't?

> >

>

> Hi Howard,

>

> I assume you recommend those uniform sizes because they're the ones used

 by


> Oracle (copy-cat ;). So you would make separate LMTs of these uniform

 sizes


> and place appropriate objects in the right tablespaces ? And if you place

 an


> object in one incorrectly (because the users were way off in their space

> guestamites), then move it to it's correct tablespace (else why separate

> them) ?

>

> However, IMHO, you uniform sizes don't make much sense.

>

> Because it suggests that if you have a (say) table in the 1M tablespace

 but


> it grows and becomes 100M in size (or 100 extents) then it really should

> have gone in the 8M tablespace (else why have it). By having uniform sizes

> that are only a magnitude of 10 or so different, it suggests that anything

> substantially more than 10 extents is undesirable. And we both know what

> rubbish that is.

>

> So why such a tiny magnitude of difference ?

>

> I can see why you're leaning towards autoallocate ....

>

> When dealing with LMT extent sizes, I lean towards a 1M uniform size. And

> that's it.

>

> If an object is large, let it grab the extents it needs. If an object were

> to require 10,000s of extents, then it's going to get either partitioned

 or


> a tablespace on it's own. If a table is tiny, I lose something under 1M.

> (with SAP it's a little different because of the number of tiny tables so

 I


> might be a bit tighter with storage wastage)

>

> In almost all scenarios, 1M is an ideal extent size and I don't have the

> disadvantage of Oracle grabbing larger chunks of storage unnecessarily

> (unlike autoallocate).

>

> I guess I'm suggesting 1M at a time, rather than multiple of 64Ks at a

 time.


> In the end, I guess it's not that much of a difference.

>

> Cheers

>

> Richard

>

>