RE: RE: Performance tuning book

No, the most complete and detailed queueing theory thing I've ever done is Chapter 9 of the book. You might be thinking of "Batch Queue Management and the Magic of '2'", which is a completely different thing.

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-----
rgaffuri_at_cox.net
Sent: Tuesday, October 21, 2003 3:05 PM
To: Multiple recipients of list ORACLE-L

there is a queuing theory article on hotsos. you have to be a member to read it... does it have more detail than what is in your book?

unfortunately i havent had a chance to read it yet. Ill get to it. Everyone I know who has read it, really liked it.

>
> From: "Cary Millsap" <cary.millsap_at_hotsos.com>
> Date: 2003/10/21 Tue PM 03:49:24 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: 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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <rgaffuri_at_cox.net
  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).