Re: Locally Managed Tablespaces - any cons???

> > > I disagree, I'm afraid. Locally managed temp tablespaces are strongly
> > > supported and encouraged (indeed, in the 8i DBA course, the syntax
 example
> > > for creating a TEMP tablespace is pure LMT... they don't even mention
 the
> > > old, DMT, way of doing it.

Ok, I have done some research on the subject. I spoke with one of my DBA's who recently went to the tuning class. They are teaching to use LMT's for the temp segments. The one issue that I couldn't clarify was are they suggesting that you use a regular or temporary tablespace that is locally managed? My guess is temporary, but she couldn't answer that question.

Using LMT makes sense, but I still have the concern, being bit by Oracle Bugs before, using it in my 24x7 databases.

One of my other concerns was the ability to tune after the fact. From what I can tell if you use the migrate_from_local in combination with migrate_to_local you can do it. Since migrated tablespaces are still locally managed as far as extents go you still have some flexabilty with this.

> Not in dictionary managed tablespace, it shouldn't. It's a multiple of
 the
> sort_area_size, PLUS one block. But yes, in locally managed tablespace,
 we
> can dispense with that extra block.
>
> > and they should have a fixed extent size.Tough to change if they are
 locally
> > managed with a fixed extent size thats wrong.
>
> True enough... which is why extent sizing in locally managed tablespaces
 (of
> any sort) is very important to get right... but that's not really an
> argument for dispensing with their services altogether! In any event,
> stuffing up your extent sizes with dictionary managed tablespace is not
> exactly easy to fix for existing segments, either. The point you are
 making
> is: choose extent sizes wisely. That's true for either sort of
 tablespace.
>
> Actually, it's more complicated than that in any case: sort area size is
 (at
> least in 8i) session-modifiable. Which means that a one-size-fits-all
> temporary tablespace is not a good idea in any event, and whatever type of
> tablespace you go for. If your code goes around modifying sort_area_size,
> it may need to alter the temporary tablespace to be used, too.
>
> And once you admit of that possibility, you rationale for dictionary
 managed
> temp tablespaces starts fraying at the edges.
>

Agreed, but most apps don't take advantage of that, and I have many temp tablespaces that I use for the different types of connections.

> >Same goes for your RBS.
> >
>
> That one I don't follow. RBS needs a fixed extent size: yup, that's why
> (thank God!) PCTINCREASE is 0 for rollback segments and can't be changed.
> What does locally managed tablespace absolutely guarantee... er, fixed
> extent sizes.
>

You didn't get the point. The necessity to change them was. And using the info that I mentioned above migration to and from local might still allow that to occur.

> > My point isn't that it is a bad idea, I am just a little more cautious
 with
> > something that can effect my system that dramatically. I do use LMT,
 but
 I
> > am just not ready to give up the control for those two just yet. Maybe
> > soon.
>
> Well, don't upgrade to 9i, then! Rollback segments cease to exist (unless
> you *want* to work in the old way), to be replaced by Undo Segments that
> manage themselves. Provided they are created in locally managed
 tablespace.
>

The issue isn't that I like to manage my rollback segments, but the necessity to do so is. In 9i I happen to like the fact that there is nothing that I can/need to do to eliminate ORA-1555 and other RBS types of errors. I don't need to verify that my RBS is large enough to handle my transactions, but small enough to handle the number of users that I have.

Perhaps the ideas that you have brought to this thread are good, and should be used. You have made me do some research that honestly I really wasn't ready to do yet. Working for one of the largest shipping companies in the world, my primary responsibility is first and foremost to keep the systems up 24x7 with 99%+ uptime. My second responsibility is to make them perform at their optimum. In keeping with those requirements, I will often opt to not use "New" technology immediately after release (immediately in our world is less than 6 months to a year).

This thread has been fun, and I will say your ideas have intriged me. Received on Mon Aug 13 2001 - 16:06:12 CDT