Oracle Scratchpad

June 8, 2008

Scientific Method

Filed under: Philosophy — Jonathan Lewis @ 9:53 pm GMT Jun 8,2008

I’ve finally found out why I seem to disagree with Don Burleson more frequently that I do with other people on the internet.

From a recent OTN thread:

Me: “you’re supposed to design a theory to match the facts, not select the facts to match the theory.”

Burleson: “I think it’s the other way around, Jonathan, the scientific method requires that you start with a hypothesis.”

So that’s my problem – I let the facts stand in the way of a perfectly nice theory.


May 16, 2008

Best Practices

Filed under: Philosophy — Jonathan Lewis @ 7:26 pm GMT May 16,2008

[The Philosophy Series]

This is a note that I wrote for the Northern California Oracle User Group a few months ago. It was published in the February issue of the magazine in the section “Ask the Oracles”, an interesting and innovative section that I first contributed to in August 2006 with a note on hints.


January 17, 2007


Filed under: Philosophy,Troubleshooting — Jonathan Lewis @ 9:26 pm GMT Jan 17,2007

A quotation from Leslie Lamport in “Specifying Systems” (ISBN 0-321-14306-X):

The hardest part of writing a specification is choosing the proper abstraction. I can teach you about TLA+, so expressing an abstract view of a system as a TLA+ specification becomes a straightforward task. But I don’t know how to teach you about abstraction. A good engineer knows how to abstract the essence of a system and suppress the unimportant details when specifying and designing it. The art of abstraction is learned only through experience.

With a little mangling, this is a sentiment that seems to be appropriate to the art of trouble-shooting. 

I can tell you all sorts of things about the way Oracle works, and describe various ways of making best use of the database engine, but (apart from the trivial cases – like missing indexes, or massively undersized memory, or silly numbers of disks) I can’t tell you how to look at a set of  symptoms and extract the essence of the problem; I can’t tell you how to suppress the unimportant details and expose the root cause of the most important issue. It’s a skill that gets honed with experience.

Fortunately, unlike the analyst or designer,  you don’t have to wait for the experience to come to you; you can construct examples that generate intersting symptoms, then start playing them off against each other to see how problems interfere with each other, and how symptoms overlap, but can still be differentiated. This is a thought I’ll come back to again.

[The Philsophy Series]

« Previous Page

The Rubric Theme. Blog at


Get every new post delivered to your Inbox.

Join 5,682 other followers