Re[2]: Oracle 911 Article

Jonathan Gennick <jonathan@xxxxxxxxxxx> · Fri, 5 Mar 2004 09:24:03 -0500

Friday, March 5, 2004, 4:19:21 AM, Michael Thomas (mhthomas@xxxxxxxxx) wrote:
MT> I don't know if this is agreeing or disagreeing with
MT> you'all, but I did not like the article.

I read Don's article, and did not like his comments about
people who take a scientific approach. On the other hand, we
are sometimes not so kind to him here on this list.

One thing I did agree with from Don's article: sometimes you
do need to fix something twice. Sometimes you need a
quick-fix of symptoms from a problem, which you can and
should follow up later by fixing the problem's root cause.
Having said this, you still need some diagnostic method,
some process to follow that leads you to a quick-fix that
will work.

Reading Don's first case-study, the one about the single
table with statistics and all the others without, I gather
that his diagnostic process seems to have gone something
like this:

1. He realized the client had just moved a new system into
production, which led him to ask questions relating to
common mistakes (e.g. not collecting statistics).

2. Further discussion uncovered a recent change: the DBA had
analyzed a single table in order to find out the average row
length.

3. He undid the change.

The above does not strike me as a particularly bad approach.
Here's a question to think about: would you, even in the
face of knowing that the client had recently analyzed just
one table, persist in applying a method such as Cary's? Or,
given the pressure you and the client would be under, would
you have a go at undoing that change first?

The problem, of course, is that you could all too easily end
up in one of those try-this-try-that-try-another-thing
loops, and those are the sorts of loops that methods like
Cary's avoid.

I'm sitting here thinking about it, trying to answer my own
question. What would I do? I don't like to apply a fix
without doing some due-diligence to be sure it will have the
desired effect. If I had faith in what I was told by the
client (you won't always have this), and if I could strongly
correlate the beginning of the poor performance with the
analyzing of that one table, and if I could be reasonably
certain that a whole bunch of other changes hadn't been made
that might muddy the diagnostic waters, I *might* go down
the unscientific path of quickly unanalyzing the table, to
see whether I could get a quick hit.

Best regards,

Jonathan Gennick --- Brighten the corner where you are
http://Gennick.com * 906.387.1698 * mailto:jonathan@xxxxxxxxxxx

Join the Oracle-article list and receive one
article on Oracle technologies per month by 
email. To join, visit http://four.pairlist.net/mailman/listinfo/oracle-article, 
or send email to Oracle-article-request@xxxxxxxxxxx and 
include the word "subscribe" in either the subject or body.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: