Expectations of Oracle Technical Books – The Path to Positive Book Reviews

5 07 2010

July 5, 2010

It might appear that my last two, three, four or maybe even five Oracle Database book reviews were a bit harsh.  In some of the blog articles leading up to the last two book reviews I pulled out a sentence or two from the book and offered readers of this blog an opportunity to comment on the accuracy of the quote from the book.  Was I just nit-picking the book’s contents, or is there a reason for the analysis?

It is probably best to start by defining some of what I believe to be the most critical key targets for a technical book:

  • A technical book must be non-fiction – a technical book should describe technically accurate details of an event, action, or object.
  • A technical book is a permanent record of an event, action, or object.  With that in mind, the contents of a technical book should require a significant amount of research, testing, and retesting to verify the accuracy of the book’s contents not just in a Linux virtual machine, but also in physical hardware on Unix, Linux, and Windows.  If the book’s technical content only applies to a Linux virtual machine environment, readers will likely experience trouble implementing the suggestions in a production environment.
  • A technical book that describes a feature should correctly identify with which Oracle release version the feature works.
  • A technical book that describes additional cost options such as partitioning, AWR, Database Replay, etc. should identicate that the feature must be purchased and/or is not available for the Standard Edition.
  • A technical book that describes Oracle initialization parameters must avoid mentioning the hidden initialization parameters unless a warning is provided that such parameters should not be modified without first consulting Oracle support.  Mentioning that warning a hundred pages after the description of the first hidden parameter is of limited help.
  • A technical book that states feature X is 25% (or any percent) more efficient than feature Y should provide a reproducible test case so that the reader is able to test the efficiency improvement in their environment as well as adapt the test case to more accurately model a problem in the reader’s database configuration.
  • A technical book should provide forward and backward references to help readers locate detailed or advanced adaptations/implementations located elsewhere in the book.  Also helpful are references to external resources found in other books, Metalink/MOS, or specific websites.
  • A technical book that contains “recipes” or “lab projects” should provide all of the critical configuration elements within a couple of pages of the “recipes” or “lab projects” – forcing the reader to page through hundreds of pages to piece together the “lab project” is unexceptable.
  • A technical book that advertises “undocumented secrets” or “definitive” or “complete” on the front cover had better contain actual undocumented (not in the Oracle documentation and not in Metalink/MOS and not found easily through an Internet web search) facts and/or contain the complete description of the topic.
  • A technical book should look like a technical book: 10 point or smaller font size, small margins, no cartoon drawings, well organized topics and sub-topics, few if any spelling or grammar errors, helpful table of contents and index, meaningful chapter names, few unnecessary distractions, etc.
  • A technical book should draw the reader in – trick the reader into reading the book cover to cover even when the weather is better suited to outdoor activities.
  • A technical book’s author(s) should have a reputation for producing accurate information about the subject – a Google search is helpful.
  • A technical book should cover the current release of the product (Oracle Database), as well as older but still supported releases.
  • And last, but not least, a technical book should convey useful content that helps people just starting to learn Oracle Database, as well as people who have used the product for years and are just looking for new ideas or a way to help maintain their knowledge.   A technical book that introduces nothing new is of limited value.

I certainly do not know everything about Oracle Database – in actuality I probably know very little about everything that there is to know about Oracle Database.  To say that it bothers me when I find errors in technical books, especially about Oracle Database, is an understatement – especially when it is something as commonly understood as the description of the db file scattered read wait event.  Spelling errors, especially when an Oracle feature or  initialization parameter are involved, simply should not be present – odd synonyms for well known Oracle keywords also should be avoided to limit confusion.  A clear, professional writing style is appreciated.

If I buy a technical book and do not receive the above, I feel a bit cheated.  The above will hopefully explain the seemingly harsh tone found in a couple of my book reviews.

What are your thoughts?  What are your expectations when reading a technical book?

References – links to my last couple of book reviews:


Late edit/addition – links to five more of my Oracle Database technical book reviews (most recent listed first):