Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: LMT is preferred than DMT.. but then

Re: LMT is preferred than DMT.. but then

From: yls177 <yls177_at_hotmail.com>
Date: 28 Mar 2004 20:46:35 -0800
Message-ID: <c06e4d68.0403282046.1cdb5763@posting.google.com>


"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40628111$0$8358$afc38c87_at_news.optusnet.com.au>...
> "yls177" <yls177_at_hotmail.com> wrote in message
> news:c06e4d68.0403242107.1a47d200_at_posting.google.com...
> > "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:<406117eb$0$31906$afc38c87_at_news.optusnet.com.au>...
> > > "yls177" <yls177_at_hotmail.com> wrote in message
> > > news:c06e4d68.0403231921.171231e6_at_posting.google.com...
> > > > i am surprised... i am on oracle 9i with datafiles of over 30gbs
> > > > each.. and my tablespace management is dictionary....
> > > >
> > > > will i have lots of problem if i switched them all over to LMT during
> > > > the process
> > >
> > > If everything is working fine, why switch at all?
> > >
> > > *IS* everything fine?
> > >
> > > You can't "switch them over" to LMT. You can use a package supplied by
> > > Oracle if you want a half-assed botch job, for sure. But otherwise,
> > > conversion to LMT means creating new tablespaces which are LMT and then
> > > moving tables, indexes and other segments over to the new tablespaces.
> > > That's a lot of I/O. Will that pose you a problem? I can't answer
> that... I
> > > know nothing about your maintenance windows or your service standards.
> It's
> > > an issue that has to be faced, though.
> > >
> > > Fortunately, you could migrate to LMT little by little, table by table.
> > > There's no law that states everything must become LMT at the same time.
> > >
> > > Regards
> > > HJR
> >
> >
> > isnt it evident enough that LMT is going to last , and better
> > performance?
>
>
> No. What "better performance" do you think you're going to get with LMT that
> you lack with DMT?
>
> Unless you have a million and one different segments all deciding to
> allocate or de-allocate extents at once, such that the data dictionary
> tables UET$ and FET$ then experience massive contention, you are unlikely,
> ever, to be able to measure a performance difference between an LMT and a
> DMT.
>
> The big benefit of LMTs, and the reason why, over time, you should indeed
> slowly migrate toward them, is that they free the DBA up from worrying about
> the number of extents, and the size of those extents. That's all. It's a
> convenience thing. not a measurable-performance thing.
>
> Are LMTs "going to last" and DMTs aren't? Yes, I suppose that's true, given
> that in 9iR2 DMTs can't be created any more if SYSTEM itself is LMT. But so
> what? If you have a 9i database with SYSTEM being DMT, what do you care *for
> that database* whether DMT has a future or not?? DMTs are obviously doing an
> adequate job right now, right this second. OK... maybe they'll have
> disappeared completely by the time version 11z comes out. Not exactly a
> major issue for a here-and-now 9i database, is it?
>
> Especially since "converting" to LMT is not free: done properly, it will
> generate a lot of I/O and potentially cause a lot of performance issues
> whilst it does so.
>
> > also, conversion to LMT has to depend on the types of applications
> > running on oracle?
>
> I don't understand that question. How data gets physically stored is of no
> interest at all to the application. Therefore, be you a warehouse, data
> mart, OLAP, OLTP or other system, it makes no difference as to the question
> of whether you should use DMTs or LMTs.
>
> The only issue that arises, I think, and maybe this is what you were getting
> at: perhaps an OLTP system will be 24x7 whereas a data warehouse might have
> weekend maintenance windows. In which case, it's going to be hard to find
> the physical time to perform a move to LMTs in the 24x7 OLTP system, but
> easier with the warehouse.
>
> If that's what you were getting at, fair enough.
>
> Regards
> HJR
>
> PS. Nothing in Oracle should be considered "evident" until it's been tested.

hi.. thanks for the sharing of opinions Received on Sun Mar 28 2004 - 22:46:35 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US