Two stars may be a little harsh; I'm sure the author is very knowledgable. However, there is a difference between making a lot of true statements and imparting knowledge to someone else (explaining).First, be warned the book only is relevant to Oracle 7 and 8i. Oracle 9 tuning is not addressed. A lot has changed in Oracle 9 because of the automatic tuning features, so I feel this book is out of date and it is shameful that book sellers disguise this fact.
There is a lot wrong with this book from the standpoint of someone who needs to tune Oracle. If you are a full time DBA and spend a lot of time studying Oracle and Oracle is your life, then perhaps this is a useful book for your collection. In that respect, the "101" in the title is perhaps accurate - it opens the subjects that you will need to dig a lot deeper into in order to really get something useful done. However, if you need a guide to tuning your Oracle database, you probably will be lost and frustrated using this book.
The author in opening chapters lays out a tuning methodology which is basically "measure performance; locate bottleneck; tune appropriate component". Then he pretty much abandons that methodology and stuffs the book with brief descriptions of how Oracle does this and that, some related parameters, and some very general advice to wrap it up. But unless you take it much further yourself with other references and deep study, you will be hard pressed to know how to fix anything.
Many Oracle books I have come across suffer from the problem of being either 3 times too long or 1/3 as long as necessary. In other words, the author needs to choose a useful format: either simply provide an overview roadmap to more detailed information, or go the distance and provide a detailed enough amount of information to get the job done. This author similarly needs more or less to make this text useful.
I can't say the book is useless. Occasionally the author does give a brief formula or rule of thumb for sizing some parameter. But they are few and far between, and usually not in very important areas.
What most of us need is a "Tuning Guide". That is, a step-by-step methodology where measurements are taken and parameters are estimated based on the measurements for tuning the database. Iterative tuning may be required, but that's OK if it is layed out as such. As you work your way through the methodology, your Oracle instance and application come into "tune". I don't know if such a methology can be designed; experts may claim it requires "intuition" and "experience". If so, then don't bother writing a book; otherwise, it is the author's job to turn intuition and experience into a methodology that others can follow.
If a "Tuning Guide" is not the intent of the author but rather more deep understanding, then the author must follow the approach of building a crystal clear "model" of the system which identifies measurement parameters for estimating the state of a real system and identifies the "control parameters" which affect the performance of the system. Then the reader should be able to measure the system and perhaps deduce how to control the performance. This book falls far short of that goal.
Here is an example from the book that left me helpless:
"CAUTION: It is very counterproductive to Oracle system performance to over-allocate memory to one or more components of your shared pool. Over-allocation of memory here can and will cause significant parsing delays (in some cases we have noticed ten-minute response times for a query such as - select * from dual;)."
Then the author does not provide any real criteria as to when I might be straying into such a disasterous region. He goes on to talk about "free memory" for various shared pool area pools, and on careful study you might deduce that too much "free memory" could be a related problem, but then rather than give any formulas or hard advice, he covers his "bases" with the wishy-washy statement: "The key here is to manage the space appropriately and make use of all the available pools in your version of Oracle." I'd love to - tell me how!
I won't dwell on his erratic writing style which frequently tosses in chirpy lingo such as the subheading: "Hey, Oracle - What Is Your Plan of Action (P.O.A.)?". His use of analogies is weak and half-hearted such as his analogy for resource contention with "children all wanting the same toy".
Basically, you know when you have a killer book that is a great tool in your toolkit. This one ain't it.
