Sorry for the delayed response – I was trying to understand how Tanel’s article applied to my blog article. Now that I have started SQL*Plus, I think that I understand your points. Tanel’s document shows how to get information about various ORADEBUG commands from within SQL*Plus. One of the commands that Tanel shows is this one:

ORADEBUG DOC EVENT FILTER process

When I execute that command in SQL*Plus (when connected as SYS), I receive the following output:

Usage
-------
{process:  ospid           ,
           orapid          ,
           pname            }

In the above it should be clear that PID should have been listed as OSPID in the book (you mentioned this also) and I think that Dom also picked up on the inconsistency. It was this oddity combined with the phrase “rest of event specification” and the overall similarity including the spacing in the command that lead me to believe that the oraclue.com article linked above might to related to this section of the book.

Regarding the syntax being valid just like “WHERE 1=2″… now that I think about it, you might have a point. Neither throws and error, and both prevent something from happening. But then editing a spfile with a text editor might also meet that criteria.

My testing showed that ALTER SESSION will only enable a 10046 trace for the current session. ALTER SESSION had no effect on the tracing that was enabled in another session. If one were to replace “alter session set events ‘sql_trace {process : n…” with “alter SYSTEM set events ‘sql_trace {process : n…” then tracing may be enabled in another session if the process ID is specified correctly.

I wonder if someone were to use the above syntax to enable tracing at the database level if that tracing would survive bouncing the database? Reviving an old article:
http://hoopercharles.wordpress.com/2010/02/12/tracing-enabled-for-sessions-after-instance-restart/#comment-3932

—

Out of curiosity, has anyone enabled a 10046 trace at the SYSTEM level (likely with an ALTER SYSTEM call) and then not been able to stop tracing for some of the sessions (possibly the background sessions) without bouncing the database? I thought that I recalled seeing this problem on Oracle Database 10.2.0.2, but a quick test on 11.2.0.2 did not reproduce the problem.

Very good comments. Your third bullet point is what forced me to stop and ponder while reading the book. So, can ALTER SESSION be used to alter the session of a specific session other than your own by using the new Oracle tracing syntax? I was curious, so I just had to test to verify my assumptions.

Your fifth point is also very good – why use your own database terms when Oracle Database itself uses different ones? Confusion should not be a desired end result in my opinion.

If you set out specifically as an 11g performance tuning recipes book then I don’t have a problem with using a syntax that only works in 11g onwards.

I would have expected “alter session” to only affect your own session so I would expect it to be pointless to set sql trace for a process pid which wasn’t your own. Similarly, even if you do know your own pid, you shouldn’t need it for alter session.

I could understand using “alter session” to set sql trace on for your session only for a specific sql_id.

The syntax does seem a bit confusing in that “pid=” should reference v$process.spid whereas “orapid=” should reference v$process.pid.