RE: Performance tuning book

Ryan,

Your two questions have different answers.

I studied mathematics as an undergrad. I focused on the abstract stuff: predicate calculus, language theory, functional analysis, topology, .... In my studies I constructed many, Many, MANY proofs. (A "proof" in mathematics is a piece of technical documentation in which loopholes are impermissible.) I never heard of queueing theory until I had to figure out how to predict performance at an Oracle project I was leading in 1994.

It might be a fun indulgence to say that to be a good Oracle performance analyst, you have to model yourself after me, but it's just not true. The honest answer is that many of the best performance analysts I've ever met have backgrounds that are all over the map: History, Theology, Economics, Geology, Music, .... Some of the great ones do have a Mathematics background (Jonathan Lewis, for example), but accusations that you must have a CS, EE, or Math degree to be a performance analyst (or to understand "Optimizing Oracle Performance") are patently absurd.

I've written about what I think are the most important traits for the performance analyst in Chapter 1 of the book. This chapter is the one that's available for free at www.oreilly.com. I think relevance, common sense, self-confidence, and the ability to communicate effectively are much more important (and actually more difficult to learn) than a lot of the more obvious educational factors.

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-----
Ryan
Sent: Tuesday, October 21, 2003 7:04 PM
To: Multiple recipients of list ORACLE-L

what is your math background? what level of math would you recommend performance specialists to have?
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Tuesday, October 21, 2003 3:49 PM

> 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ryan
  INET: rgaffuri_at_cox.net

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).