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).

Uniforms never fragment, and autoallocates might, that's true. But the autoallocate algorithm is pretty sensible, and you end up with 64K, 1M, 8M 64M extents... and all of those are divsors of the other, so if I truncate a table and free up 3 1M extents, than I am going to be able to fit plenty of 64K extents within it without a problem.

Compare that with DMTs where (in the absence of MINIMUM EXTENT) you could have 84K extents, 93K extents, 17456K extents and God knows what else.

>
> > 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.

TEMP anyone? (OK, only the initial allocations, perhaps) Rollback segments anyone? (Potentially all the time).

>
> I don't like LMTs for the following reasons:
> - with uniform I need to know the size of the object from the beginning

Why? If you're not sure, bung it in a 64K eextent tablespace. When you acquire 100 extents, move it to the 1M tablespace and so on. There is less requirement to know your sizes in LMT than there ever was in DMT.

> - with system managed LMTs I end up with fragmentation (64k, 1M, 8M
extents)

Mere;y having differently-sized extents is *not* fragmentation. It's whether a segment can make use of the space freed up by the truncating or dropping of a segment. The use of those multiples means fragmentation is minimised in autoallocates.

> and a huge number of extents

Who cares? The number of extents isn't an issue in LMTs. It *was* an issue in DMTs, where a huge number of extents meant a huge number of records in UET$ and FET$ and corresponding chaining in the data dictionary. But we're not using those tables now.

> - access to dba_extents is unacceptable slow when >2000 extents are
> allocated

Depends on the system, I think. But if you're worried about it, move the table to a bigger-extent LMT and thus reduce the number of extents.

> Even on 9i, I used DMTs (not for undo and temp).

I'd get out of the habit if I were you. It's quite clear that DMTs will be abolished at some point in the future, as srvmgrl and internal were before them.

Regards
HJR
>
> Stephan
>
>
>
>
Received on Mon Feb 03 2003 - 14:15:02 CST