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.
May 16, 2008
January 17, 2007
Philosophy
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.
