I ordered the "Oracle Database 11gR2 Performance Cookbook" book shortly after it became available for purchase. I was very curious to see how the book compared with the similarly titled "Oracle Database 11g Performance Tuning Recipes" book, as well as some of the other Oracle Database performance books that are on the market. Packt is a fairly new book publisher, and this book marks the first Packt book in my collection.
The author of this book does not appear to be widely known in the international Oracle Database community, although it does appear that the author is an active reviewer of SQL Server and programming books on an Italian programming focused website. The author's LinkedIn page indicates that he obtained OCA and OCP certification in 2002 and 2003, respectively, has a variety of programming experience, and currently is an IT Manager.
One important characteristic of this book that is missing from some of the other Oracle Database performance focused books on the market is the extensive use of test case scripts throughout most of the book that allow the reader to reproduce the performance changes mentioned in the book, in the reader's Oracle Database environments. The test case scripts, related screen captures, and author's explanations of the results are both a blessing and a curse for this book. It appears that the author used a single Amazon Elastic Compute Cloud hosted database instance with only one set of instance parameters and system statistics for the various test case results and the author's descriptions of the expected outcome when the inputs in the test case script are provided. Had the author re-executed the test case scripts in another Oracle Database environment, the author probably would have written quite differently the explanations that follow the test case scripts. It is not uncommon for 80% of some of the book pages to be consumed by one or two SQL*Plus screen captures; combined with the slightly larger font sizes, double-spacing between paragraphs, and apparent one and a half spacing between lines in code sections, the technical content in the book is a bit more limited than the page count might suggest.
So, how well did the book's contents meet the level of expectations provided by the book's front cover and the publisher's description of the book? One of the bullet pointed descriptions of the book reads, "Avoid common myths and pitfalls that slow down the database." Unfortunately, the book reintroduces several myths and inaccurate conclusions about Oracle Database that have diminished in frequency during the last 10+ years. Some of the information in the book is of good quality. However, the significant number of inaccurate, vague, misleading, and/or over-generalized facts in this book suggests that the author of this book may have not received sufficient guidance from Packt and the four technical reviewers of the book. The book publisher's site currently lists no errata for the book, even though I personally submitted 21 errata items to the publisher's errata reporting site.
The author's native language is obviously not English, so it is probably to be expected that some of the sentences in the book are incomprehensible. Yet, there are also sentences in the book that use completely different phrasing, close to that of a person who double-majored in English and computer science with a focus on Oracle Database. The consistent usage of the term "fields" in some sections of the book, with the consistent usage of the term "columns" in other sections of the book is but one example of the style shift that is present in the book. Some of the sentences found in the book are oddly familiar, and although I was not able to identify the original sources of all of the oddly familiar sentences, I did manage to locate a few. What constitutes plagiarism in an Oracle Database book, and how much change is required to the original material to avoid the plagiarism label? Would slightly reformatting a section of text to replace dashes with colons be sufficient to avoid the label? Would changing the order of some sentences and eliminating other sentences be sufficient to avoid the label? Would performing simple word substitutions here and there, or shortening sentences be sufficient to avoid the label? I am not suggesting that there is rampant plagiarism in the book, but one does need to question when that plateau is reached in a book about Oracle Database.
While in some respects this book is more useful to the reader than the "Oracle Database 11g Performance Tuning Recipes" book due to the inclusion of test cases, both books seem to omit the reasoning behind why and when someone might consider performing the 80 or so tasks/recipes mentioned in the books. Vague, inaccurate, over-generalized, and out of date descriptions of Oracle Database behavior are limiting factors of both books. This review is quite long, and likely will not appear in full on Amazon - see my blog for the full review.
Data Dictionary Views:
* DBA_VIEWS (page 20)
* V$FIXED_TABLE (page 21)
* V$LIBRARYCACHE (page 52)
* V$STATNAME, V$MYSTAT (page 53)
* SYS.SEQ$ (page 65)
* DBA_MVIEWS, USER_MVIEWS, ALL_MVIEWS (page 69)
* INDEX_STATS (pages 127, 128)
* V$SYSSTAT (page 160)
* V$SESSION (page 205)
Parameters:
* CURSOR_SHARING (pages 9, 38)
* TIMED_STATISTICS (pages 20, 201)
* LOG_CHECKPOINTS_TO_ALERT, BACKGROUND_DUMP_DEST (page 28)
* STATISTICS_LEVEL (pages 29, 32)
* CONTROL_MANAGEMENT_PACK_ACCESS (page 32)
* QUERY_REWRITE_ENABLED, QUERY_REWRITE_INTEGRITY (page 70)
* DB_16K_CACHE_SIZE (page 84)
* MAX_DUMP_FILE_SIZE, TRACEFILE_IDENTIFIER (page 201)
* SQL_TRACE (page 202)
Hints:
* APPEND (page 72)
* INDEX (page 121)
Comments, Corrections, and Problems:
* The book states, "The first rule in writing applications which connect to an Oracle Database is to always use bind variables, which means not to include parameters in SQL statements as literals." The statement should be clarified that this is a general recommendation. There are times when literals should be used rather than bind variables, for instance if there are very popular and unpopular values in a column, it might be wise to prevent the sharing of execution plans when a very popular or very unpopular value is used in the WHERE clause. A correction/clarification is provided on page 51 (page 8).
* Steps for creating a database with the Oracle Database Configuration Assistant seem to be out of place in a performance tuning book (pages 17-19)
* Uses the term "fields" where the term "columns" should be used (page 21).
* The book demonstrates the use of ANALYZE TABLE ... COMPUTE STATISTICS, and DBMS_UTILITY.ANALYZE_SCHEMA to collect object statistics. The book states that ANALYZE is retained for backward compatibility, but the book provides no warning that using ANALYZE to collect statistics could be problematic since the release of Oracle Database 8.1 (reference page 21).
* The book uses the word "elaborate" rather than "create" or "generate" (pages 24, 26, 27, 31, 37)
* The book demonstrates the use of AWR without first mentioning the licensing requirements of that feature (pages 30-31).
* Word substitution error: "... and we experiment a lack of performance in another period, we can elaborate two reports..." (page 31)
* The book demonstrates the use of ADDM without first mentioning the licensing requirements of that feature. The book also states, "ADDM is enabled by default in Oracle Database 11g; it depends on two configuration parameters..." Unlike with Oracle Database 10.1 and 10.2, ADDM is not enabled by default in the Standard Edition of Oracle Database 11.1 or 11.2, nor can it be legally enabled on the Standard Edition. While ADDM is enabled by default in the Enterprise Edition 11.1 and 11.2, it cannot be legally used without a Diagnostic Pack license (pages 32-35).
* The book suggests the system-wide use of the deprecated SIMILAR value for the CURSOR_SHARING parameter as one of two solutions to address a hard parsing problem in a test case script (page 38).
* The book states, "Now the Soft Parse is 97.84 percent." The output shown in the book actually indicates a Soft Parse percent of 99.20. The instance efficiency numbers in the output are identical to those found on page 40, so this might be an indication of a copy-paste error (page 39).
* The book states, "If the PreparedStatement is not closed, it can be executed multiple times - changing the value assigned to bind variables - and only a `light' soft-parse will occur, with no syntax and semantic check." If the SQL statement is held open - there will NOT be a "light" soft-parse (session cached cursors are not discussed in this section of the book, which would allow a "light" soft-parse if the cursor is NOT held open) (page 52).
* The elapsed time comparison between the directly executed SELECT statement, and the REFCURSOR that is returned by the SH.
Read more ›
