Re: Performance problem

# That seems to me to be a fairly logical way to go about tackling the
# problem at hand - if, say, the disk change alone corresonds to 95% of

# the extra time, then you've found your culprit.

What if something application related or outside of the recent hardware problems caused the differences?

The hardware changes may conceivably not have affected it one way or another.

Remember the OP had a big problem with how long the batch was running even before the changes.

Concentrating on hardware changes "while a familiar" approach to many is not an optimal or even likely way of getting to root problems.

Only after following a proven methodology should one think about hardware implications or considerations.

#> Experimenting with further changes and/or "backing out" some or all of
#> the recent changes is exactly "what not to do". #> Shooting in the dark is not recommended.

# I agree that farting around randomly with extra changes is
essentially
# pissing into a Katrina - however reversing the changes made one by
one
# and separately is *_one_* reasonably good way of trying to find out
# where the problem lies.

I don't agree. Not when time is ticking by and you are not sure of what the root causes are.

# BTW, I'm not denying the value of your
# approach, I'm just saying that mine is not invalid. I would also
agree
# that your approach my turn up solutions not even imagined by the OP.

Sorry I still think the approach you recommended is a bad choice.

There is no reason to "wait" on better hardware or some new implementation of oracle.

My advice is to take the time and read Cary's book now. Received on Wed Dec 07 2005 - 13:37:17 CST