Re: Compute_statistics PROBLEM

Thanks guys.

I'am not an expert, but my opinion:

Howard is right that the switching-back to the default temp tablspace should ONLY influence the users which are assigned to temp that way, it should NOT influence the 'dedicated assigned' users.

Pete has a correct work around.

Thanks
Stephan

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:NFiY9.32392$jM5.82603_at_newsfeeds.bigpond.com...
> Pete Sharman wrote:
> [snip]
> >
> > Much as I hate to disagree with you (because I know you you have more
> > persistence with following up your viewpoint than I do with mine :), I
don't see
> > this being as big an issue as you make it, except in the situation where
you
> > have multiple applications using a single database that might therefore
need
> > different sorting characteristics.
>
> Read the archives at Google. That is an awfully lot more common an
> arrangement than either you or I might care for.
>
> >
> > I'm seeing a lot of client sites having databases dedicated to
particular
> > applications. In that case, generally you see users with similar sort
> > requirements, except perhaps for batch reporting. For those batch jobs,
a
> > differently configured temp tablespace makes sense. Now, as a DBA, are
you
> > being sensible to swap normal users to that temporary tablespace, even
if
> > there's a problem like you outlined with the normal users temp? No,
what you
> > should be doing is creating a THIRD temp tablespace, which should be PDQ
to do,
> > and then swap users to that. Since the temp tablespace is stored at the
user
> > level, it's pretty damn hard for us to store history of temp tablespace,
which
> > is what you'd need to get around the issue any other way.
>
> I agree it might not be sensible. Absolutely. But is it going to happen?
> Yup, I think so. And does Oracle then respect my explicit grants? Nope.
> That's the problem.
>
> >
> > Of course, if you are consolidating applications into a global single
instance,
> > then you won't end up with most users having the same sort requirements.
But
> > even there you can just have different temp tablespaces, and if one
fails like
> > you outlined, then create another one.
>
> Assuming you've got the space available, of course. And that you remember.
>
> >
> > The problem to me boils down to how you perform your role as a DBA.
Maybe in a
> > later release we can add a _EXPERIENCE_LEVEL parameter so the database
can make
> > intelligent decisions for you, but in the meantime you can't abrogate
your
> > responsibilities.
>
> Now, ordinarily, I'd completely agree with your sentiments here. It's
> just that, as far as I can see, it's the Oracle database itself that's
> just abbrogated it's responsibilities here. In the normal sense of the
> meaning of words, "default" is something that gets used when there's no
> other choice. So if I don't specify a temporary tablespace, the default
> steps up to the plate. But if I go to the bother of explicitly assigning
> a user to a specific temporary tablespace, that ought to be the end of
> the matter.The fact that it isn't is the database's poor behaviour.
>
> But there are bigger things to worry about, I agree.
>
> Regards
> HJR
>
>
>
>
> >
> > My $0.02 worth. Back to you! :)
> >
> > HTH. Additions and corrections welcome.
> >
> > Pete
> >
> > SELECT standard_disclaimer, witty_remark FROM company_requirements;
> >
>
Received on Sat Jan 25 2003 - 07:35:34 CST