Same table in LMT consume 10% more space than in DMT

Question

We have a table in DMT with pct_free=10, the size is 3,891,200 block, after I use impdp import it to another database with LMT manually management extents tablespace(table has the same pct_free), the size is 4,141,059. I hope the new table should be smaller than the old one, but the fact is opposite. There is nearly no update to the table, so it seems the difference is because using LMT.
Does LMT has a much higher overhead than DMT?

Answer 1

It has a much lower overhead, in fact, in terms of better coping with segments which frequently extend (no ST enqueue waits, for example).
But if you specify mad uniform sizes when creating LMTs, you will end up with mad results! There's not enough information in your post to know if that's happening here or not, but if you do:
create tablespace TB1 datafile 'tb1.dbf' size 10m extent management local uniform size 1M;
and then create a table which only stores 48KB of data in that tablespace, the table will nevertheless consume 1MB of space and look very inefficient, because that large uniform size is being applied.
How, specifically, did you create your LMT? If you said, 'uniform size 1GB', for example, then you're bound to end up with whole gig extents, and thus forced to consume 32GB when your table (say) only really wanted to occupy 31.01GB
If you let autoallocate determine the extent sizes, the same sort of effect is going to happen, but it might not be so noticeable.
I'm not convinced in any case that the difference between a table occupying 29.6GB and one occupying 31.6GB is worth worrying about: 2GB of disk space seems to me to be the least of your concerns. For the total elimination of tablespace fragmentation and ST enqueue waits, 2GB seems to me a small price to pay!