Re: LMT and DMT

"Stephan Bressler" <stephan.bressler_at_siemens.com> wrote in message news:b1lrf9$l4r$1_at_news.mch.sbs.de...
>
> <snip>
> > thing. They prevent "tablespace fragmentation" (which isn't a
performance
> > issue, but is definitely a waste of space issue).
> Are you sure? This is true in case of uniform LMTs, not in system managed
> LMTs. You can mimic uniform LMTs with DMTs, too, but choosing 3 TBS (e.g.
a
> 64k TBS for small objects, a 1M and a 8M for larger objects).

This is sort of true, but misses the enforcement aspect of LMT's. A DMT can specify default storage clauses but anyone with the create object privilege can go ahead and specify their own storage clause which takes priority and causes fragmentation.

> > They prevent contention
> > for the data dictionary when dozens of segments all decide to extend at
> the
> > same time.
> Ok, if you do a lot of space management or you have 10.000s of extents.
>
> I don't like LMTs for the following reasons:
> - with uniform I need to know the size of the object from the beginning

I'd argue that you need to know that with DMTs as well. (at least to within an order of magnitude which is all the precision you need for LMTs)

> - with system managed LMTs I end up with fragmentation (64k, 1M, 8M
extents)
> and a huge number of extents

fair comment, uniform is the way to go.
> - access to dba_extents is unacceptable slow when >2000 extents are
> allocated

This seems somewhat odd, do you mean lots of objects with >2000 extents,
>2000 extents in total in dba_extents.

Cheers.

--
Niall Litchfield
Oracle DBA
Audit Commission UK