One experience I had when using this, was it hosed our "homegrown" monitoring routine. The space calculations our sql script used (dba_free_space and dba_segments) to let us know if we had room to extend were out of whack, so I had to convert back to DMT. Later I recreated the tablespaces/tables using LMT's with uniform extent sizes. Nothing critical, but it should be noted for your production monitoring. On 6/30/05, zhu chao <zhuchao@xxxxxxxxx> wrote: > Hi, All, > We have some pretty big OLTP database suffer from ST enqueue > contention (size range from 1TB-3TB), because we use dictionary > managed tablespace and without proper extent size when > table/index/context index got created. > Now some indexes have tens of thousands of extents and whenever we > drop some unused objects(like not used index via index monitoring), we > suffer from ST enqueue, even during normal business operation time. > > We plan to use dbms_space_admin to convert existing DMT tbs to LMT > tbs, and I already did some test on test box and it seems very good > and pretty fast. > Before do any change in production, ,I would like to ask you guys, > if anyone has used it on big database and have any good/bad experience > with it. > > Thanks for sharing. > Regards > > > -- > Regards > Zhu Chao > www.cnoug.org > -- > //www.freelists.org/webpage/oracle-l > -- //www.freelists.org/webpage/oracle-l