Nice one Tim! I had indeed not thought of that. It does point out the screaming need for the ability to split the metadata in an LMT into a separate file. But that is an enhancement request, not current fact, and it would be that the "split metadata" LMT would consist of at least two files (though one would be pretty small). Definitely a valid use of DMT until and unless SM_LMT exists. As for unlimited growth earlier in the thread I just recommend a generous but achievable maxsize rather than unlimited. If something tries to grow infinitely you're going to have something go splat regardless. Regards, mwf _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Gorman Sent: Friday, December 18, 2009 11:46 AM To: mark.powell2@xxxxxx; Oracle-L@xxxxxxxxxxxxx Subject: Re: ASSM and high volume concurrent inserts Responding to the question "does anyone think dictionary managed tablespaces are ever a good choice anymore"... The one scenario where I've found DMT to be preferable to LMT is where the underlying storage is migrateable or otherwise has some initialization latency for infrequent I/O requests. Mainframes have long used hierarchical file-systems, where a seldom-accessed file is transparently moved or "migrated" to offline storage, requiring a "recall" to primary storage when the left-behind file-header is accessed. the problem that LMT tablespaces have is that every query on the DBA_EXTENTS and DBA_FREE_SPACE views requires access to the bitmapped extent-map blocks residing right in the datafile. So, in an environment that is possibly likely to grow onto such storage, now or in future, it is worth considering retaining the ability to create DMTs by creating the database with the SYSTEM tablespace DMT. Use LMT tablespaces in most situations, but convert to DMT (using DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL) prior to moving a tablespace to migrateable storage.