RE: ASSM and high volume concurrent inserts

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.

 

 

 

Other related posts: