The book was heading in the right direction, but completely missed the opportunity to demonstrate something that is useful. This recipe was about 10046 extended SQL traces, and thus apparently could not offer in the recipe format a demonstration of how what was statement might work, or offer an alternative such as that offered by Mladen above.

The multiple interpretations of the quoted section of the book probably was not intentional, but it can lead to some confusion. I agree that the term “query” is fuzzy. Does one “query” a witness to determine what happened, or does one “query” a witness to change what happened?

The quotes from the documentation are outdated. The RETURNING clause of INSERTs, UPDATEs and DELETEs return a result set as well as success/failure. They’ve always returned the number of rows affected too.

So I think it may be a case of what is wrong with the quotes from the Oracle documentation

As I mentioned, there are a couple of different potential interpretations of the quoted section from the book.

The book’s recipes jump around a bit, back and forth between topics. For example, page 340 also discusses using TKPROF to analyze 10046 extended SQL trace files time, where the book states: “time: Total time (in milliseconds) spent processing the operation”. So, are the “ela” statistics reported in microseconds while the “time” statistics in the Row Source Execution Plan are shown in milliseconds, or do the two time statistics both measure time in 1/1,000,000 of a second (the 1,000,000 could be rounded up to the nearest power of two on some operating system platforms and Oracle Database release versions). Does it matter if the reader has one Oracle 8i (8.1.7.4, for example) database as well as an assortment of 9i, 10g, and 11g R2 databases?

You could also focus on the phrase “a query was waiting on a lock”… when would a SELECT statement (using the definition from the Oracle Database Concepts guide, query… to ask a question of the database) wait on a lock? Of course, readers do not block other readers, readers do not block writers, and writers do not block readers. A SELECT FOR UPDATE might need to wait on an enqueue, but the “FOR UPDATE” clause likely does not represent common usage in a query for most applications. If you focus on the phrase “where and why a query was waiting”, as Mladen pointed out, the WHY might not be present in a 10046 extended SQL trace for a session (maybe if you compared simultaneously captured 10046 traces for multiple sessions you would find the WHY).

The following shows how I selected to interpret the quoted section, and the fule full recipe for that matter, for the book review:

Recipe 10-6 states the following, “Note that the TKPROF or other profiling tools show the elapsed times for various phases of query execution, but not the information for locks and latches. If you’re trying to find out if any locks are slowing down a query, look at the raw trace files to see if there are any enqueue waits in the WAIT lines of the raw file.” I might be misinterpreting these two sentences, but the sentences appear to be incorrect assuming that a level 8 or greater (wait events) extended SQL trace, generated by Oracle Database 10.1 (or higher), is passed into TKPROF. Starting in Oracle Database 10.1 most of the enqueue waits are divided into much more specific wait events that begin with “enq:” (there are 299 wait events in Oracle Database 11.2.0.2 that begin with “enq:”). The same is true for latches, where the “latch free” wait event is split out into multiple wait events (there are 43 wait events in Oracle Database 11.2.0.2 for latches). (pages 335-336)

Any other comments?

•A row is locked only when modified by a writer.
•A writer of a row blocks a concurrent writer of the same row.
•A reader never blocks a writer.
•A writer never blocks a reader.

http://download.oracle.com/docs/cd/A57673_01/DOC/server/doc/A48506/sqlconce.htm#1288

Queries are different from other types of SQL statements because they return data as results if they are successful. Whereas other statements return simply success or failure, a query can return one row or thousands of rows. The results of a query are always in tabular format, and the rows of the result are fetched (retrieved), either a row at a time or in groups.

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/sqlplsql.htm#CNCPT1914

Queries are different from other types of SQL statements because, if successful, they return data as results. Whereas other statements simply return success or failure, a query can return one row or thousands of rows. The results of a query are always in tabular format, and the rows of the result are fetched (retrieved), either a row at a time or in groups.

Thanks for stopping by and providing a helpful comment on the blog article. You made valid points and backed up those points with a suggested alternative (one of the planned outcomes of these types of blog article).

I initially read the quote quite a bit differently than you, and thus came up with a very different comment about what is right or wrong about the quote. I will share the portion of my book review for this recipe in roughly 24-48 hours – until then I will try to limit my comments in this article. Obviously, one of the other planned outcomes of these types of articles is to tap into the vast combined knowledge of readers so that we may build a much more complete picture of how things work than I could put together by myself.