Christian Antognini - Troubleshooting Oracle Performance

I think the best thing that has happened to Oracle performance in the past ten years is the radical improvement in the quality of the information you can buy now at the bookstore.

In the old days, the books you bought about Oracle performance all looked pretty much the same. They insinuated that your Oracle system inevitably suffered from too much I/O (which is, in fact, not inevitable) or not enough memory (which they claimed was the same thing as too much I/O, which also isn't true). They'd show you loads and loads of SQL scripts that you might run, and they'd tell you to tune your SQL. And that, they said, would fix everything.

It was an age of darkness.

Chris's book is a member of the family tree that has brought to usus... light. The difference between the darkness and the light boils down to one simple concept. It's a concept that your mathematics teachers made you execute from the time when you were about ten years old: show your work.

I don't mean show-and-tell, where someone claims he has improved performance at hundreds of customer sites by hundreds of percentage points so therefore he's an expert. I mean show your work, which means documenting a relevant baseline measurement, conducting a controlled experiment, documenting a second relevant measurement, and then showing your results openly and transparently so that your reader can follow along and even reproduce your test if he wants.

That's a big deal. When authors started doing that, Oracle audiences started getting a lot smarter. Since the year 2000, there has been a dramatic increase in the number of people in the Oracle community who ask intelligent questions and demand intelligent answers about performance. And there's been an acceleration in the drowning-out of some really bad ideas that lots of people used to believe.

In this book, Chris follows the pattern that works. He tells you useful things. But he doesn't stop there. He shows you how he knows, which is to say he shows you how you can find out for yourself. He shows his work.

That brings you two big benefits. First, showing his work helps you understand more deeply what he's showing you, which makes his lessons easier for you to remember and apply. Second, by understanding his examples, you can understand not just the things that Chris is showing you, but you'll also be able to answer additional good questions that Chris hasn't covered... like what will happen in the next release of Oracle after this book has gone to print.

This book, for me, is both a technical and a "persuasional" reference. It contains tremendous amounts of fully documented homework that I can reuse. It also contains eloquent new arguments on several points about which I share Chris's views and his passion. The arguments that Chris uses in this book will help me convince more people to do the Right Things.

Chris is a smart, energetic guy who stands on the shoulders of Dave Ensor, Lex de Haan, Anjo Kolk, Steve Adams, Jonathan Lewis, Tom Kyte, and a handful of other people I regard as heroes for bringing rigor to our field. Now we have Chris's shoulders to stand on as well.

Cary Millsap

Cary Millsap is chief executive of Method R Corporation, a software performance company. He wrote Optimizing Oracle Performance with Jeff Holt in 2003, which earned Cary and Jeff the Oracle Magazine 2004 Author of the Year award. You can find Cary at http://method-r.com or http://carymillsap.blogspot.com.

I started using the Oracle RDBMS a little more than 20 years ago, and it took about three years for me to discover that troubleshooting and tuning had acquired a reputation verging on the mystical.

One of the developers had passed a query to the DBA group because it wasn't performing well. I checked the execution plan, checked the data patterns, and pointed out that most of the work could be eliminated by adding an index to one of the tables. The developer's response was "But it doesn't need an index; it's a small table." (This was in the days of 6.0.36, by the way, when the definition of a "short" table was "no more than four blocks long.") So I created the index anyway, and the query ran about 30 times fasterand then I had a lot of explaining to do.

Troubleshooting does not depend on magic, mystique, or myth; it depends on understanding, observation, and interpretation. As Richard Feynmann once said, "It doesn't matter how beautiful your theory is; it doesn't matter how smart you are. If your theory doesn't agree with experiment, it's wrong." There are many "theories" of Oracle performance that are wrong and should have been deleted from the collective memory many years agoand Christian Antognini is one of the people helping to wipe them out.