RE: Performance tuning book

Michael, I've responded by preceding your questions with "MM:" and my answers with "CVM:".

MM: ...can you please tell me if your new book, of which I've heard good things, is different in any way than other Oracle Performance Tuning books out. Does it take a different approach?

CVM: Drastically different. Probably the most important difference is that it's the first Oracle book that doesn't espouse a method that consists of just trying things until you find something that helps. It prescribes a step-by-step process, which is the same every time, for diagnosing your performance problem. The method works for finding performance problem causes whatever in the technology stack they may be. I didn't do it this way for the sake of being different. I did it this way because the traditional ways of "tuning" don't work.

I think some other things like the queueing chapter make it different, too, but I feel that there's been too much focus placed upon the apparently deep mathematical nature of this chapter. The point of the chapter is to show people how to use a model (one that's already completely worked out for you) to gain insight into your real Oracle performance problems. At the end of the chapter is a 14-page, fully worked example. No other book does this. There are a lot of formulas in this chapter, but I show them only to help people recreate (or test) my results. For every formula, there is an Excel spreadsheet function that automates the use of that formula (some of the Excel formulas took years to develop, by the way). The chapter is all about showing the reader why performance behaves in the surprising ways that it sometimes does. It's not about showing you how "cool" math can be.

MM: Does it teach different methodologies?

CVM: It teaches a single method that is radically different from the ones most Oracle professionals are taught. You can get a drift of what I mean by reading the sample chapter at
http://www.oreilly.com/catalog/optoraclep/index.html. (By the way, I distinguish carefully between the words "method" and "methodology." I have a note about this in the book's Glossary, and at http://www.hotsos.com/e-library/oop.html as well.)

MM: Is it more readable? I'd be very interested in your own assessment.

CVM: There are three parts to the book, and the "readability" varies by design across those three parts. Parts I and III are meant to be read front-to-back by DBAs and analysts, and also their managers. Part II is reference material that I hope technical people are reading, but Part II is definitely too much to swallow in a few sittings. There's just too much detail. You can see more information about the structure of the book at http://www.hotsos.com/e-library/oop.html.

There are some tricky concepts you have to understand before you can optimize an Oracle database, so it can be difficult to write about these concepts in a manner that people can understand. I find virtually nothing more offensive in technical literature than the author who tells you that something is so complicated that you would never understand it, even if he bothered to explain it to you. I think it should be the reader's right to see the facts and decide whether to skip them or dive into them.

I think that most authors who try to complicate things are really just afraid to admit publicly that they don't know something. It's fine not to know some things. We all don't know a lot of things! But it's not helpful when an author's ultimate goal is to look authoritative instead of trying to help the reader understand what we know and what needs further study.

I know I've scared a lot of people with all the arithmetic in the queueing chapter, but here I've been especially careful to explain how to use what our good mathematical forefathers have worked out for us. You can read the entire chapter without having to know what any of the formulas mean. I've focused on what the models *mean* and how to use them, not on why they work.

So, how readable is it? There's a lot of stuff out there that I hope we're much, much better than. But it would be difficult to be more readable than, for example, Ensor, Kyte, Lewis, Morle, Vaidyanatha/Deshpande, or Lawson, who, in my opinion, write beautifully. So far, much of the feedback I've received is that the book is fun to read, which was definitely a principal design goal of the project.

MM: What did you try to accomplish with this book?

CVM: I covered much of this in the preface. Our whole company was borne of deep frustration with some of the very popular "tips & techniques" work out there that I consider to be absolute garbage. One of the principal motives of the book was to create a better classroom experience for our students (see
http://www.hotsos.com/courses/PD101.php, for example).

With the book, Jeff and I have tried to lay out a system that enables a reader to determine whether the performance information he's getting at conferences, classes, books, magazines, etc. is valid or not. We have tried to raise the bar for what people consider to be an acceptable standard for an Oracle performance analyst to meet. We have tried to further stimulate the revolution of Oracle performance methods from the very weak and inefficient checklist-based methods to a more efficient scientific approach.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:
- Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney

• SQL Optimization 101: 12/8-12 Dallas
• Hotsos Symposium 2004: March 7-10 Dallas
• Visit www.hotsos.com for schedule details...

-----Original Message-----
Michael Milligan
Sent: Tuesday, October 21, 2003 12:45 PM To: Multiple recipients of list ORACLE-L

Cary,

I don't mean to ask you to brag, but can you please tell me if your new book, of which I've heard good things, is different in any way than other
Oracle Performance Tuning books out. Does it take a different approach? Does
it
teach different methodologies? Is it more readable? I'd be very interested
in your own assessment. What did you try to accomplish with this book?

TIA, Michael Milligan
Oracle DBA
Ingenix, Inc.
2525 Lake Park Blvd.
Salt Lake City, Utah 84120
wrk 801-982-3081
mbl 801-628-6058
michael.milligan_at_ingenix.com

This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that
any dissemination, distribution or copying of this e-mail is prohibited. If
you have received this e-mail in error, please notify the sender by replying
to this message and delete this e-mail immediately.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Michael Milligan
  INET: Michael.Milligan_at_ingenix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Cary Millsap
  INET: cary.millsap_at_hotsos.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).