Comments on: Root Cause

By: Battling the Symptoms or Addressing the Root Cause « Charles Hooper's Oracle Notes

Sat, 03 Apr 2010 16:26:45 +0000

[...] An Oracle database example of this is simply throwing hardware at a performance problem because a root cause analysis is perceived as requiring too much time and being too expensive (computer hardware costs are decreasing while at the same time IT labor costs are increasing). Sure, replace the server with one having 4 times as many CPUs and 4 times as much memory – after all, hardware is cheap compared to the perceived cost of a root cause analysis (at least that is what it says on the news). Forget that such a cheap upgrade will require 4 times as many Oracle Database CPU licenses, accompanied by 4 times as much for annual Oracle support/maintenance fees. On second thought, maybe a root cause analysis is really a much better and less costly approach, no matter if the performance problem is caused by a change to daylight savings time, someone verbally abusing the SAN, an upgrade of the Oracle Database version, or something else. [...]

By: Jonathan Lewis

Jonathan Lewis — Sat, 25 Oct 2008 13:24:24 +0000

I’m sitting in Copenhagen airport, waiting for a plane to take me home after the Miracle Oracle Open World event in Lalandia.

Many of the great names in Oracle were speaking at this event – but the presentation that really stood out for me was the one by Robyn Sands on “Root Cause Analysis”.

Many of the presentations at MOOW tend to be biased towards the in-depth technical stuff – but this one made the point that we MUST ask the right questions and behave the right way BEFORE we dive in with all the high-tech stuff to try fixing a problem.

This may seem like an obvious message – but it’s amazing how rarely it gets mentioned, and Robyn put the message across very well.

If you’re coming to the UKOUG annual conference this year, Robyn will be doing the same presentation there. It doesn’t matter whether you see yourself as a developer, DBA, or manager – go to it, and learn how to avoid wasting your most valuable resource .. your time.

By: Log Buffer #117: a Carnival of the Vanities for DBAs

Log Buffer #117: a Carnival of the Vanities for DBAs — Fri, 03 Oct 2008 16:15:07 +0000

[...] other news, Jonathan Lewis talks about finding the root cause, in a different [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 30 Sep 2008 07:02:28 +0000

Charlie,

Certainly. Thank you for asking for my permission.

By: Charlie Z

Charlie Z — Mon, 29 Sep 2008 21:43:30 +0000

Hi Jonathan,

This post is really interesting. Can I reference it and translate it to Chinese in my blog.

Thanks,
Charlie

By: Gabe

Gabe — Mon, 29 Sep 2008 15:59:30 +0000

I find the expression du jour (what, pretentious, moi?) to be best practices. Nothing kills a legitimate "why?" faster than an invocation of the best industry practices.

By: Dion Cho

Dion Cho — Mon, 29 Sep 2008 08:55:49 +0000

Very interesting and, hell, it’s a quite hot and current topic – the mortgage and bankrupcy!!! :)

By: Robyn

Robyn — Mon, 29 Sep 2008 02:51:05 +0000

no worries … I did some summer reading of the current crop of RCA books. Pretentious fluff is dead on for some of it :)

By: Jonathan Lewis

Jonathan Lewis — Sun, 28 Sep 2008 18:51:52 +0000

Jeff,
I’d forgotten where the line (Pretentious, moi!) came from: but it is one of the wittiest lines I have ever heard – just two words and perfect self-reference.

Robyn,
Sorry, I’ve just checked the UKOUG agenda and realised you’re doing a presentation on Root Cause Analysis. (It’s different when it’s technicians talking about it rather than salesmen ;) )

By: Robyn

Robyn — Sat, 27 Sep 2008 03:50:55 +0000

Jonathan, I love this example but you’ve beaten me to my punchline. (well, one of them) In IT, we can’t always fix the root cause: it’s beyond our control, our budget or our time constraints. But the more we know about the cause of the problem, the more likely we can correct it and stop it from reoccurring. Resolving the economic crunch would fix the problem in this example and a lot of others but since that can’t be controlled, understanding the changing load on database helps identify what is necessary to deal with the new conditions, and with that understanding the best option can be chosen.

Many good dba’s already look for the ‘root cause’ even if they never use the phrase. I’d suggest that they try the terminology out on management; sometimes speaking in their language gets the point across better. (damn, there goes the second punchline .. now what will I talk about?)