| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re[2]: Oracle 911 Article
Friday, March 5, 2004, 4:19:21 AM, Michael Thomas (mhthomas_at_yahoo.com) 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:
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@gennick.com
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_at_gennick.com and include the word "subscribe" in either the subject or body.
 |
 |