* Sigh * More on Myths

Well I've ploughed my way through Part 2 of the article here, and have come away even less impressed.

quote: In this, our last installment we examine the nature of Oracle myths and understood how changing technology effects mythological status.

That may have been the plan, but the opening sentence is the last we hear of this. I believe that "mythological status" and "the status of myths" are two completely different concepts, by the way.

quote: Today we see two “types” of Oracle Professionals, each saying that other Professionals are perpetuating new Oracle Myths. In one group, the “Researcher” seeks “laws”, tautologies about Oracle behaviors that are true, while the Empiricist seeks “correlations” and deals in probabilities rather than absolutes.

WTF "happened" to the doublequote "key" in this "sentence"? And isn't a tautology always true by definition? Does the author know the meaning of the word tautology? I doubt that anyone one claim that what researchers seek are "empty or vacuous statement[s] composed of simpler statements in a fashion that makes [them] logically true whether the simpler statements are factually true or false".

quote: Many Research Professionals believe that “rules-of-thumb” (ROT) are very dangerous, and note that if an ROT can be shown as invalid, even in a single artificial test, the ROT is not scientifically valid

In general things that are shown to be invalid are not scientifically valid. In fact, things that can be shown to be invalid are generally not valid, full-stop. It's called an "oxymoron".

When are rules-of-thumb dangerous? When they are applied without thought or understanding, often under the influence of a mentor who actively discourages understanding by telling people to just trust them, even when their advice is demonstrably incorrect.

quote: Detractors note that simple, generalized “rules” form the basis for many of the Oracle 10g automation features, such as Automatic Memory Management (AMM) and the SQLTuning advisor.

AMM uses simple generalized "rules"? Or simple generalized rules? There we go with the double-quotes again. Based on previous postings, I don't believe that Mike knows how it works. SQLTuning advisor may indeed use simple generalized "rules" (or rules, whatever), leading to debacles such as the one described here. So much for simple, generalized rules.

quote: This myth says that running single-user SQL*Plus scripts to “prove” how an Oracle change will behave in production are almost always invalid under multi-user database activity. Detractors say that it is not necessary to run large-scale, multi-user benchmarks to “prove” how Oracle behaves.

Read that first sentence closely. "This myth says that running blah-blah-blah to "prove " blah-blah-blah are almost always invalid under multi-user database activity." "... are almost always invalid"? Very poor and clumsy grammar. Moving along though, this is a lovely dismissal of Robin Schumacher's "indexes love large blocksizes" script.

And what does "almost always" mean? What a vague and useless phrase. If I demonstrate with a script that an index organized table can be accessed with multiblock reads, is that invalid in a multiuser environment? Nope.

quote: So, are these myths? Borrowing from Don Burleson’s hilarious DBAZine article “What type of DBA are you?”, we see several Oracle personality types. In fairness, he created these deliberate generalizations to illustrate the mindsets of the Empirical and Scientific professionals.

So now we're supposed to decide whether these technical issues are myths based on an allegedly-hilarious article that deliberatly generalizes mindsets? There we have the essence of the "empirical" "mindset" -- don't discuss the technology, don't try and understand the internals, just use smoke and mirrors to detract from the lack of substance.

quote: Empirical professionals utilize the heuristic approach to observe behavior and apply it to new situations. ... Heuristic 1. A rule of thumb, simplification, or educated guess that reduces or limits the search for solutions in domains that are difficult and poorly understood. Unlike algorithms, heuristics do not guarantee optimal, or even feasible, solutions and are often used with no theoretical guarantee.

Hmmm, so professionals are using a method that does not guarantee even a feasible solution, eh? Hopefully that's spelled out in the consultancy agreement. "The client acknowledges that their domain is difficult and poorly understood, and that the consultant's solutions shall not be guaranteed to be feasible." Where do I sign up for that then?

quote: The Empiricist DBA does testing with benchmarks, not test script.

A fine distinction, I expect. Not helped by the following.

quote: Does this mean the Empiricist blindly charges in making bold changes to clients databases without testing, checking statistics, waits, IO rates and timing and myriad other factors before applying heuristics?

Oh so the empiricist does test -- presumably not with a script however. With some other technique. The same technique used to check statistics, waits, IO rates etc.. But not a script, right?

quote: The Research DBA has the motto is “Prove it,” and “Trust, but Verify”.

OK, that's the last grammar warning. "... has the motto is ..." indeed!

If this is the case then the empiricist's motto(s) must be "Don't bother proving it" and "Trust without verifying" I guess.

quote: The Research DBA believes that a database can be described with simple SQL*Plus test scripts and every assertion about database behavior can be proven with such research.

No they don't. That's what someone would want you to believe if they wanted you to distrust research methodologies in favour of just "trusting the wise consultant".

quote: Mark Rittman notes that the Empirical DBA approach is problematic because it suggests that novices cannot become expert in Oracle tuning without many years of experience

Not just problematic, but downright wrong. Novices can become expert in Oracle tuning by understanding the internals of Oracle and the way that problems can be detected.

quote: Some authors are misleading their trusting followers with the mantra of “Prove it”, and they never note that “your mileage may vary”, especially for performance-related proofs.

Some authors post articles on how indexes and temporary tablespaces love large block sizes with neither proof nor "your mileage may vary" disclaimers. However when given a test script, anyone can test exactly how much their mileage will vary before (for example) rebuilding their database with a 32kb system blocksize in order to get a 32kb temporary tablespace size, which it turns out is a complete waste of time. A series of scripts could have proven to them that temporary tablespace access uses direct i/o. Instead, I guess they just trusted the expert. * sigh *

quote: Often when faced with real-world situations they will retreat into the mantra “Rebuild the entire application and call me in the morning…”, a response that while is probably true, doesn’t really help in the real-world where down time or lost time results in lost money.

I have no idea what "rebuild the entire application" means, but apparantly it's "true". Does that mean "valid"? I have no idea. I'm sure that there are anecdotes available to *ahem* "support" this stereotype.

quote: The research DBA believes the Empirical DBA is lax and sloppy, and does not pay enough attention to details.

Some of them are, I expect. There's always lax and sloppy people in every profession, but that doesn't mean that they're all empirical. The problem is that when an empirical consultant is lax and sloppy you have absolutely no way to find out. When someone bases their advice on facts, then you have the basis for discovery.

quote: They make bold assertions about Oracle behavior that can be shown wrong under certain circumstances ..

"... that can be shown to be wrong ...".

quote: The Research DBA believes that the Empirical DBA is a “loose cannon” and cannot understand their impatience and disregard for elegant proofs and detail. Secretly, they think that the Empirical DBA is dangerous, and cringes at their propensity to rush into every database problem without supporting justification.

Not "secretly" at all. Here: "Advising someone to create their database with a 32kb system block size in order to reap a temporary tablespace performance advantage is dangerous, and it makes me cringe, and I believe that there is no valid justification for it". There you go.

quote: These “Script Kiddies” don’t test their hypothesis on large multi-user databases and they don’t understand how a high concurrency and load Oracle environment will change the results.

Their hypotheses are written down, and are therefore testable of large multiuser databases. They do understand how a high concurrency and load environment will change the results because they understand the internals of Oracle.

quote: They believe that the scientific method is the only way to effectively approach an Oracle performance problem, and all broad-brush tuning (changes to system-wide parameters, using faster hardware) are unscientific, non-elegant and offensive.

"Yes" to the first part, "rubbish" to the second. You change system-wide parameters when required, and you use faster hardware when required. And ironically there is no such word as "non-elegant" -- it is just an inelegant way of saying "inelegant".

quote: With math you can prove that for a given gravity well, a feather and a lead ball will accelerate at the same rate toward the center of that gravity well. In the real world we know the affects of the surface area to weight and resistance will result in widely different rates of acceleration.

Yeah, that whole lead ball and feather thing has been a mystery to scientists since ... erm ... oh hang on no it isn't a mystery is it? It's called aerodynamics, or fluid dynamics, and it is pretty scientific stuff as far as I recall.

quote: The successive refinement of their heuristic rules form the experiential basis for “expert” Oracle tuning as noted in the book “Oracle Silver Bullets”.

Yeah there's nothing like backing up your arguments by mentioning a book written and published by your empirically-inclined employer, although when you put the word expert in doublequotes it kind-of implies that you don't think that he's an expert, Mike. Just a little career tip for you there. ;)

quote: This from Robin Schumacher, author of “Oracle Performance Troubleshooting”: http://www.rampant-books.com/book_2003_1_perf.htm ... It's fine for DBAs to perform trials and postulate theories as long as they realize those theories may crash and burn in the real world. Or, as someone well said a while back, "watch out when a beautiful theory meets a brutal gang of facts."

Does that apply to his "indexes love large block sizes" script as well, d'ya think?

quote: While single-user proofs validate how Oracle reacts in a single-user environment rely on real-world benchmarks whenever possible for decisions involving multi-user systems.

But if that benchmark "proves" that you should use a 32kb block size to make your temporary tablespace access more efficient, then run like hell.