Re: LMT is preferred than DMT.. but then

"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. Received on Thu Mar 25 2004 - 00:49:51 CST