Nice catch. Yes, clarification was necessary, thanks.

On a CPU starved server, db file sequential read waits (along with other waits) will very likely require longer to complete. Cary Millsap’s book also essentially mentioned that the log file sync wait event is one of the first wait events that shows signs of CPU starvation. The second half of your statement is what I was trying to state – the spin while trying to acquire a latch consumes CPU cycles, but the time in the spin will not be registered to a wait event.

Your comment demonstrates one of the benefits of this blog – readers of the blog help to improve the clarity (and occasionally accuracy) of the articles, and occasionally take the articles into an interesting, tangent topic.

Millsap teaches that CPU starvation causes inflated wait times [ the waiting session not only waits for event completion as usual, but also must wait longer for its turn on CPU which can inflate the wait time ( WILL inflate the wait time on a CPU starved system ) ], however in support of your statement, a session that is trying to get a latch can also spend significant CPU time spinning between latch waits, which time would not be recorded in any wait event.

Thanks for this blog..

Thank you for solving that mystery… 3 years before the question was asked on AskTom.

As promised, my explanation that will appear in the formal book review:

Recipe 4-10 incorrectly states that the “Parse CPU to Parse Elapsd” statistic found in an AWR report is “how much time the CPU is spending parsing SQL statements…” The book’s definition of this statistic is incorrect – the statistic actually indicates delays (wait events) in the parsing of SQL statements, very likely due to contention between sessions (or possibly excessive competition for the server’s CPUs, however such competition probably would not be captured in an Oracle wait event). Ideally, this statistic in an AWR report should be close to 100%. It appears that the book authors attempted to describe the “PARSE TIME CPU” statistic, which is not found in this section of an AWR report, or attempted to describe a derivative of the “Non-Parse CPU” statistic which does appear in the Instance Efficiency Percentages section of an AWR report (page 133-134).

Nice find for a blog article that directly references the Parse CPU to Parse Elapsd metric. You probably noticed that I intentionally erased the “(Target 100%)” from the posted sample Instance Efficiency Percentages sections that are included in this blog article – just to see if anyone would notice.

I thought for sure that someone would provide a link to AskTom. I found the following thread link yesterday:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2159478097863

In the above thread is the following Instance Efficiency Percentages output:

Buffer Nowait %:             99.98    Redo NoWait %:    100.00 
Buffer Hit %:                99.91    In-memory Sort %:  99.88 
Library Hit %:               99.89    Soft Parse %:      99.23 
Execute to Parse %:          75.94    Latch Hit %:       99.94 
Parse CPU to Parse Elapsd %:  0.00    % Non-Parse CPU:   93.89 

According to the quote from the book, the above Parse CPU to Parse Elapsd metric would be infinitely better than either of the two sample Instance Efficiency Percentages sections that I included in the blog article.

However, Jonathan Lewis wrote a blog article warning us about jumping to conclusion when using the Instance Efficiency Percentage without considering at least the load profile and, particularly, its “per second” figures
http://jonathanlewis.wordpress.com/2006/12/27/analysing-statspack-2/

Take another look at the description provided in the quote, and take a closer look at the Non-Parse CPU statistic in the Instance Efficiency Percentages samples.

Is there anything else about the statistics in this section of an AWR/Statspack Report that might be useful? How about the Buffer Hit %?