I Didn’t Know That 1 – What is Wrong with this Quote?

December 9, 2010

(Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 995:

“In the 1970s, Moore’s law was introduced, stating that processor costs were always falling while speed continued to improve.  However, as Oracle professionals, we must understand that Moore’s law does not apply to RAM.  While RAM costs continue to fall every year, the speed of RAM access is constrained by silicon technology and did not improve over at least three decades as shown in Figure 17.1.”

What, if anything, is wrong with the above quote?  While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

• dba-oracle.com/art_dbazine_oracle_10g_data_warehouse.htm
• dba-oracle.com/oracle_tips_hardware_oracle_performance.htm
• dba-oracle.com/t_history_ram.htm

Helpful References:

• http://www.intel.com/technology/mooreslaw/
• http://en.wikipedia.org/wiki/Moore’s_law

Wait Events 3 – What is Wrong with this Quote?

December 9, 2010

(Back to the Previous Post in the Series)

While reading the “Oracle Tuning the Definitive Reference Second Edition” book I found a handful of interesting suggestions regarding Oracle wait events.  Previous articles on this blog have described the contents of 10046 trace files, and leveraged the contents of those files to explain various types of problems and/or unexpected behavior (for example: three part series reading 10046 trace files, EXPLAIN PLAN/AUTOTRACE/TKPROF lies, ORDERED hint not followed, four part series: Enterprise Edition and Standard Edition perform differently, 11.2.0.1 ODBC bug, etc.)  Take three minutes to analyze the following quote from page 451 of the book that describes Oracle Database wait events found in 10046 trace files:

“Those Evil Wait Events in the 10046 Trace File

The trace file contains lots of details and it is important to seek out the wait event notes as the wait events are interspersed throughout the 10046 trace file.

WAIT #2: nam='SQL*Net message to client' ela= 10 p1=1111838976 p2=1 p3=0

This wait event record shows that the wait event (nam) is a SQL*Net message to client.  These wait events are the same wait events that can be found in the database in the v$ views like v$session_wait or v$event_name.

The elapsed time (ela) is in microseconds since this database is Oracle 10g, so this wait was a whole 10 microseconds.  This is nothing to worry about because 1 second = 1,000,000 microseconds.  Please note the P1, P2 and P3 variables are specific to each event.”

Keeping in mind that the book is printed after the release of Oracle Database 11.2.0.1 (and possibly 11.2.0.2 for some operating system platforms), what, if anything, is wrong with the above quote?

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

• dba-oracle.com/t_10046_trace_file_parse_execute.htm