Banned By Burleson!

Boy, I thought it would never happen. I thought that by being reasonable and polite (yet irritatingly insistant) I would never get banned by Don Burleson from his Oracle DBA Forum.

I guess the post where I satirically responded to Mike Ault's blog entry with my own version, in which I satirically suggested that DKB used a crystal ball to diagnose Oracle database problems, gave him the excuse that he needed to remove a thorn in his side. Hey, if Mike wasn't blocking comments from his posting then I wouldn't have felt the urge now, would I?

How did all this happen? Well, it's a long and sad story.

Some weeks ago DKB posted an article (or did it start off as a forum posting? I don't recall) in which he suggested that Oracle users were getting excellent performance improvements by moving their indexes to tablespaces with large block sizes. "Sounds interesting!" I thought. "Let's see what sort of improvement we're talking about here!". So I ran some simple SQL*Plus scripts in which I compared CPU usage and wall clock time for both fast full index scans (FFIS) and index range scans (IRS) for indexes of the same size, on the same data, with one index on 8kb block size and one on 16kb block size.

Result: well, nothing to write home about to be honest. Nothing to rave about, certainly. But Don had a user quote attributing "a 20% reduction in I/O" to this technique (what kind of I/O, on what range of objects, over what time period, for what load, we don't know).

So either there was something wrong with the script (could easily be the case) or something was wrong with the advice. Don went for "something wrong with the script" -- in fact he went a stage further and said that such simple SQL*Plus scripts didn't mean anything because they weren't predictive of performance on a "real world system". Now my interpretation of Don's position is that the only things that mean anything in terms of real-world performance are either articles giving generic advice without any qualification on system type or load (eg. his original artical) or a full-blown system benchmarking process on the target system. Rather non-intuitively, intermediate steps between "trust-me-I'm-a-professional" and "full-blown-system-test" are worth less than either of these extremes. Extraordinary -- but also convenient.

So that thread went on and on and on and on. I would ask for any evidence, speculation, or wild guess as to why the script was not valid, and Don (and Mike too, if memory serves) would just ignore it. At one point a forum member (I forget who, but I'll be happy to give credit if someone will remind me update: diogenes tells me it was the pseudonymous ora_dba_guy, and that sounds right to me -- thanks D and ODG) suggested that the 20% performance improvement might be due to a number of other factors, including just the fact that the index was rebuilt as part of the move process. Now, that suddnely made absolute sense to me. Don is a proponent of index rebuilds in some situations, so maybe he'd acknowledge that the rebuild process was responsible for what improvement there was.

Nope. Apparantly not. Or maybe he does agree, but I don't recall a reply. I can't check now because I've been banned, right? And to be honest, Don has established a pattern of editing posts critical of him, so I wouldn't trust the results anyway.

So the interested reader might like to pop over to the forum and check things out, and read what others think over at http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:38264759390157 - maybe let me know why I've been banned as well. Don hasn't let me know, although he has my email address of course. He's getting pretty adept at banning dissenters, editing threads, closing them, deleting them. Does he still have that post in there about how no-one is banned, and there are no filters on the forum? Maybe not.

Maybe he thinks that he is now free to post scripts such as ...

select /*+ index(emp_bitmap_idx) */
count(*)
from
emp, dept
where
emp.deptno = dept.deptno;

... http://www.dba-oracle.com/oracle_tips_bitmapped_indexes.htm in which he believes that the index hint takes as it's argument the name of the index alone. Clang! Either the table name or alias, or the table name/alias and the index name. Hands up all those who think this script was tested? That error just jumped right out at me.

Also, why is it a "common problem when implementing bitmap indexes" that the CBO may chose to use a FTS if your table is small? Anyone? That's what it's supposed to do! It is not a problem!

And I appreciate that 100 distinct values is a "rough" guide but again it's plain wrong. If you have a table with 100,000,000 rows in it then you can make use of a bitmap index on a column with 10,000 distinct values or more.

Why do I know these things? Because I do them every working day, hands on with Oracle. And to think that just a month ago Don was asking me if I wanted to be a tech reviewer for his publishing company, and to spot article errors for him. How the mighty are fallen ;)

Oh, and here's what I posted in response to Mike's satirical blog ...

Client: Mr Burleson! Thanks goodness you've come! We had an expert in here looking at our performance problem, but it would take too long to get a result from him, so we've called you in. You need database access?

DKB: Pah, not a bit of it. Didn't you know that you can't "prove" anything with a script?

Client: Uh, OK. So what do you need then?

DKB: Just let me get my crystal ball plugged in a sec ... um ...

Client: Yes?

DKB: OK, got it. Here's my recommendation. Rebuild all your indexes, moving them to 32kb tablespaces. Then rebuild them every two weeks, get yourself some SSD hardware, more memory, more processors. Got it?

Client: That's it?

DKB: Sure. If you have any more problems, call me in and I'll give you another customized solution.

Client: Should we do any measurements of performance before and after the changes?

DKB: Well, as long as you don't use a SQL*Plus script to do so, you ought to be OK. Oh, don't forget to increase the number of LGWR processes.

Client: ???

Now the funny thing about Mike's blog is that he implied that the "Oracle Scientist" was being unreasonable in demanding database access to perform the following ...

• Looking at data and relationships
• How data is used.
• the physical relationships of your entire database
• how all the indexes are built
• how all the tables are configured
• root cause analysis of all waits and events.

Funny list. Like, funny-ha-ha, because most of those are not what is required, right?

Here's some highlights of his own list (which is actually a pretty good one)

• Wait events
• IO spread and timing
• Log events
• Memory statistics and parameters
• SQL usage
• SQL statements which require too many resources
• Access statistics if in 9i and 10g, otherwise major problem SQL is analyzed.
• Parameter settings
• Disk IO
• CPU usage statistics
• Memory usage statistics

Wait events top of the list. Look, he's measuring stuff. Suppose the client did have access to the code, would he look for poorly performing SQL with a view to changing it? I bet he would.

You see, Mike's not just writing articles that say "move your indexes to tablespaces with large block sizes" at all! You know what? I think Mike's in denial, because I think that he may secretly be an Oracle scientist! He doesn't realise it because from his list above he doesn't know what an Oracle scientist is. He's just been criticised so often in the past by people associated with that methodology that he doesn't want to be associated with it.

But I don't believe that of Don. I've seen too many basic errors in scripts that he's published, and too much generic advice that he cannot defend on it's technical merits. I've seen him advise people to create tablespaces with names that start with a digit (an elementary and obvious error, that makes an experienced Oracle professional's hair stand on end) and to create tablespaces with non-default block size before creating the appropriate memory structure (anyone who has actually done this themselves knows it has to be done in the reverse order to that originally stated in the article). I pointed out those errors and he corrected them, by the way.

So, when is Oracle going to institute a "Banned By Burleson!" award? The list of inductees is getting longer by the day, it seems, and eventually the only members of Don's forum will be gullible noobies and Burleson Consulting employees -- eventually the noob's will grow out of it though. Eventually we could have a "Banned By Burleson!" banner on our web pages, and a stamp on our business cards to advertise our rationale approach to our profession. If anyone would like to take that thought and run with it then they'll have my full support, for one.

By the way, I'm allowing comments on this. No bans, no filters. Flame away!