Oracle Database 11g Release 2: Performance Tuning Tips and Techniques (Richard Niemiec)

I've been asked by the publishers to review "Oracle Database 11g Release 2: Performance Tuning Tips and Techniques" by Richard Niemiec of TUSC. Conclusion: it is good but not perfect. This is an extended version of the review I put up on Amazon.

The book is aimed at "helping beginner and intermediate Oracle professionals" (page 2). Presumably that means knowledge equivalent to OCA or OCP qualifications. For the intended market it should be excellent, if (like me) you are OCM, you will learn not that much.
The good stuff first: chapters 2 (indexes), 6 (explain plan), 7 (hints), 8 (query tuning), 9 (joins), 10 (pl/sql), 11 (parallelism only - ignore the stuff about Exa% and RAC, they can't be covered in just a few pages), 12 (v$ views) and 13 (x$ tables) are excellent and make the book worth the price.
Some other chapters may be interesting, but they aren't essential reading: chapters 1 (new features), 5 (Enterprise Manager), 15 (a system review method), and 16 (some Unix commands). These could be cut out to bring the book down to a more manageable size. Speaking of which, 3 pages for the dedication and 8 pages of acknowlegements is certainly excessive. The appendices (another 100 pages) are also valueless.
Three remaining chapters are good, but have problems. Chapter 3 on discs and ASM does go on about placing files on different discs to eliminate contention. This is dreadfully old fashioned, and I assume has been copied from previous versions of the book. I hope everyone knows that best practice is to stripe all your file systems across all your discs. Chapter 4 (initialization parameters) is also out of date: it goes on about tuning with hit ratios, which is very 20th century. Chapter 14 (AWR and Statspack reports) is good as far as it goes, but it misses a critical topic: there is no mention of DB Time and v$sys_time_model, even though this is the first part of a report that many DBAs will go to.
Now the bad stuff. First, the technical editing is poor. All authors make mistakes (I certainly do) and the tech editors are meant to catch them. Just a few incontrovertible examples:
Page 4, the description of Exadata storage indexes is wrong, "...which cells need to be accessed..." should read "...which blocks need to be accessed..." Pages 21,22 include an example of code to set up a flashback data archive, which ends with a query that can't work because it projects a column that isn't in the table. On page 334, the first example can't work because the hint is missing the table name. There are many more like this, I'll send all the ones I spotted to McGraw-Hill for inclusion in the errata sheet. This is not trivial: things like this can be confusing or misleading for the reader: be sure to download the errata.
Second, the really bad one: the author is wrong on how redo is generated. Page 147 gives a description of redo which suggests that only committed changes and changes to undo segments generate redo, but that uncommitted changes do not. Page 782 compounds the error by suggesting that redo is no longer written to disc in near-as-damnit real time (and of course it is real time on commit), and page 866 makes it even worse by saying that whole blocks (not change vectors) go to the log buffer (as in release 5, perhaps?). Related to this is the wrong description of the log_buffer parameter (page 204, repeated on 1004) which states that the log buffer is used for "uncommitted transactions in memory". It also says incorrectly that you cannot set the parameter in an spfile. Understanding redo is critical, and is a very worryong failure.
Third, not so serious I suppose but still bad, is the description of immediate requests for a latch. Page 894 says that an immediate, or "not willing to wait", request means that the session will keep retrying immediately, which is nonsense. A not willing to wait request means that the session will go off and do something else, instead of waiting.
So overall, the book is very, but read it critically. There are many excellent scripts tat will let you test any points you are not sure of, or where you suspect an error.