I appreciate your comment regarding my book reviews.

My reviews do not identify all mistakes in the books that I read, but I try to cover as many of the easily identified errors as possible, and do my best to cover all of the difficult to spot errors (yes, I miss several of these errors in a typical review that other members of the Oracle community could easily identify). I also make an effort to identify the positive points of the books that I review, and in some cases that is a challenging exercise.

There is still a possibility that the “Oracle Database 11g Performance Tuning Recipes: A Problem-Solution Approach” book could be very good as a finished product. Right now, I would rate the alpha copy of the book chapters at 2 out of 5 stars based on a close look at recipes 3-1 through 3-6 and 3-12 through 5-7. Take, for example, the following quote from recipe 5-3: “For example, if you see the db file sequential reads event (indicates full table scans) at the top of the wait event list, you must look a bit further to see how the database is accumulating these read events.” The next 3 sentences in the book are just as logically accurate as this one. Another example from recipe 5-7 that describes how to resolve log file sync waits, “Instead of committing after each row, for example, you can specify that the commits occur after every 500 rows.” This is later followed up by the statement “The log file sync wait event can also be caused by too large a setting for the LOG_BUFFER initialization parameter. Too large a value for the LOG_BUFFER parameter will lead the LGWR process to write data less frequently to the redo log files.” – didn’t recipe 3-13 tell me that there is no risk in sizing the LOG_BUFFER parameter too large? Sure, go ahead and tell the readers to modify the hidden parameter _log_io_size (without providing any warnings about modifying hidden parameters), and fail to mention that excessive time spent in the log file sync wait event could be caused by a CPU starvation condition.

I know from personal experience that the Apress editors are very good at spotting logical errors where one portion of a chapter is inconsistent with another portion of a chapter. The Apress editors are also very good at looking at what is written and letting the author know that a section must be rewritten so that the content can be understood by the reader. I *hope* that the technical reviewers of this book are also recommending adjustments for content accuracy.

In case it is of any interest to readers of this blog, the following article shows what I expect when reading a technical book:
http://hoopercharles.wordpress.com/2010/07/05/expectations-of-technical-books-the-path-to-positive-book-reviews/

Keep up the brilliant job you do!!

Dani