How come SQL*Net had some statements …
Because the database was waiting on SQL*Net sometime during or after the statement (but before the next statement)
You can go here in the Oracle docs to see what the meaning of each event is.
Wait events are associated with a statement. In some cases, the statement won’t complete until the wait is finished. In other cases, the statement is already finished, and the associated statement just happens to be the last statement finished before the wait event.
In the example I have above, #18446741324892192776 refers to the cursor number. So, somewhere in my trace file, I can find a line that says:
Parsing in cursor # 18446741324892192776 (followed by the statement itself).
That’s how I connect waits to statements.
When a COMMIT or ROLLBACK is issued (or some other event that causes a transaction to finish, like DDL), you’ll see lines like this.
XCTEND rlbk=1, rd_only=1, tim=32135479409461
WAIT #0: nam=‘SQL*Net message to client’ ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-40016363 tim=32135479409533
WAIT #0: nam=‘SQL*Net message from client’ ela= 575 driver id=1413697536 #bytes=1 p3=0 obj#=-40016363 tim=32135479410150
XCTEND indicates the transaction.
The Wait#0 lines are what appear in the “Transaction Waits” grid. These waits are more related to the ending of the transaction than the prior statement, but I have to put them somewhere, so I put them with the prior statement.
Cary Millsap has a good book called “Optimizing Oracle Performance” that covers understanding of trace files (among other things). I used this book as a reference when writing the Trace File Browser. It has a section that walks you through a trace file line by line, explaining what each line means.