Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re: Oracle 911 Article

Re: Re: Oracle 911 Article

From: <>
Date: Fri, 5 Mar 2004 10:38:24 -0500
Message-Id: <>

can someone provide a link to this article? I missed it. I get too many emails....

about the part where oracle support recommends burleson. consider the insane rates Oracle charges for consulting services( i know guys who have billed 6 times their salaries) and the total cut throat nature of the management team, I doubt they would recommend any former employees. It means less business for them?

have any now former oracle employees been recommended by oracle?
> From: "Richard Foote" <>
> Date: 2004/03/05 Fri AM 08:49:43 EST
> To: <>
> Subject: Re: Oracle 911 Article
> Oracle 911 ArticleI'm not sure if it was a technical article or an attempt
> at a resume !!
> It certainly has it's amusing moments. Can you imagine the scene. A patient
> lies critically ill on the surgery table when the doctor suddenly utters
> "Shit, some bastard has just gone and deleted all the statistics from our
> "Where To Find Bodily Parts (WTFBP)" database, we're doomed". "Oh No"
> exclaims the nurse, "quick, someone fetch Don" !!
> Strangely what he calls "Unconventional Methods" I call "Conventional and
> Elementary Methods" in tuning trivial problems. Problem: missing indexes
> Solution: create missing indexes, Problem: missing statistics Solution add
> missing statistics, etc doesn't sound particularly "unconventional" to me
> (although if the site is migrating to CBO, I would prefer to just go back to
> the RBO as a safer emergency solution, if not migrating then what the hell
> happened to all the stats bar one table)
> His "Contrary to the pontifications of theoreticians and ivory-tower
> academics, there are many silver bullets for Oracle performance tuning"
> comments could possible by aimed at yours truly, for which I would be deeply
> flattered for the complement. However as I work full-time as a DBA dealing
> with real databases in real production environments solving real problems
> (how I wish it was always as simple as Don's examples), I might
> unfortunately be mistaken.
> I think the preamble where Don yet again prattles on about "Silver Bullets"
> is an attempt to save some face following criticisms he received after his
> "Silver Bullet: optimizer_index_cost_adj" article. However, considering he's
> subsequently re-written the whole thing and retitled it with the "Silver
> Bullet" title removed, perhaps even Don might agree that such criticisms
> were justified, else why all the changes ? Maybe the "ivory-tower academics"
> had a point ... Of course there are silver bullets, here's a big list of
> them is still his stubborn claim though. What he fails to realise is that
> they're not silver bullets at all but specific solutions to specific
> problems which maybe of benefit in specific situations. If for example the
> optimizer_index_cost_adj parameter is a silver bullet, why not have used
> this silver bullet in all the FTS problems ?
> This is where I kinda agree with Jonathan. For a DB article, it actually has
> it's good moments in that at least he attempts to narrow down and describe a
> specific problem, he attempts to justify an appropriate solution and he
> attempts to see the impact and the positive effects of applied solution. He
> may have a dislike for those that practice a scientific approach to database
> administration but at least he's making an attempt to follow some of the
> basic steps.
> Where the article falls down for me is the numerous errors that again
> proliferate throughout. Time and again DB lets himself down with error after
> error after error in an article. It just tarnishes the whole thing and dents
> the credibility of the author. The errors also makes the claim that all the
> stories are true somewhat questionable in that much of the "evidence" that
> supports the "stories" is inconsistent or plain wrong (eg. using alter
> system commands to change the optimizer parameters, interestingly now fixed,
> the faked statspack reports as it's a little difficult to believe that two
> separate databases had issues with identical schemas and table definitions
> and even had an identical number of FTS for one of the tables, solving a
> different problem to that listed in the top 5 wait events, the faked top 5
> wait events as the wait times and % wait times are inconsistent in all the
> top 5 wait reports listed, putting tables in the buffer pool that aren't
> listed in the report, etc, etc). If the evidence is made up, what does that
> say about the rest of the article ...
> Finally, the Oracle Support comment. Does Oracle Support really recommend
> Don and other external consultants when the customers gets confused with OS
> instructions. Hopefully we'll find out as I posted a question on metalink
> out of curiosity.
> In summary, the article has it's moments and provides some useful pointers
> when dealing with simplistic tuning problems. But the ever present errors
> and the silly preamble and tone again tarnishes the whole thing.
> Richard
> ----- Original Message -----
> From: David Wagoner
> To: ORACLE-L (E-mail)
> Sent: Friday, March 05, 2004 8:29 AM
> Subject: Oracle 911 Article
> You guys are going to enjoy this :-).
> I just read a very interesting article that managed to insult some of my
> favorite Oracle authors and the entire state of Alabama! Now I've heard Mr.
> Burleson speak before, and I must admit that I thought he was a dynamic and
> entertaining speaker. But do you really think that Oracle Support has ever
> told anyone to call HIM to solve their performance problems (his article
> makes this claim)? Does anyone else find the tone of this article
> unbefitting of an Oracle professional with such extensive credentials? I
> honestly can't believe that published this, especially
> considering that Oracle is listed as one of their sponsors.
> Best regards,
> David B. Wagoner
> Database Administrator
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ:
> ----------------------------------------------------------------
> To unsubscribe send email to:
> put 'unsubscribe' in the subject line.
> --
> Archives are at
> FAQ is at
> -----------------------------------------------------------------

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Fri Mar 05 2004 - 10:24:04 CST

Original text of this message