Oracle made big improvements to its diagnosability infrastructure in database version 11g. Every major kernel function and component has been instrumented with the new dbk*/dbg* debug functions and can be traced with ORADEBUG.

Before 11g, the previous Oracle diagnostic events infrastructure had much more limited syntax and usage.

Very shortly, the new 11g kernel debug & diagnostics infrastructure allows you to be much more precise when tracing & dumping diagnostic info. For example, the below example would dump SQL Trace only when running the SQL with SQLID 32cqz71gd8wy3 below and the pgadep 0 means that only trace when the SQL is executed from top level (directly by application) as opposed to from recursive context (like SQL fired from PL/SQL or data dictionary queries where dep>0 in SQL trace):

The plan_stat=all executions above is yet another 11g improvement, which dumps the STAT# lines (execution plan & execution statistics from last execution) at every execution of the cursor as opposed to only when the cursor is closed.

For low-level diagnostics, you can even enable tracing/actions only when the current function call stack contains a specific function name (or prefix), like in below case I only trace things happening in the execute phase of the SQL (opiexe stands for Oracle Program Interface Execute):

Another example enables kernel tracing (not SQL trace) for all Oracle components which are part of the RDBMS.SQL_Transform component family. The tracing is only done when the SQL statement executed has SQLID 32cqz71gd8wy3. I have enabled tracing to a tracefile (if the components have anything to trace) and additionally I have enabled three additional actions every time any events in SQL_Transform are hit and the SQLID scope is met. 

Note that this syntax is experimental here, it's not widely used and this particular case below probably dumps a lot of detailed info, which is not useful for everyday regular troubleshooting tasks. I wrote such syntax for illustrating the full power of the new debug infrastructure:

Now the optimizer SQL Transformation engine tracing would happen only when executing the SQLID mentioned above and additionally three dumps (query_block_dump,processstate and current call stack) are performed every time this SQLID execution hits events in the SQL_Transform module.

Here's the full syntax of what you can use starting from 11g onwards, you can extract all this yourself by using the new command ORADEBUG DOC:

There's a new command ORADEBUG DOC for showing all the new syntax that oradebug supports:

The syntax immediately below shows that it's possible to assign actions (action_list) to events (functions, code locations in Oracle) and make these actions fire only in specific conditions (when event scope (SQL_ID) and filter conditions are matched).

This syntax allows you to get more information about parameters for some events (especially these ones suffixed with [ ] in above output):

The event filter allows you to fire event actions only when certain event filter conditions are met, like only when a specific (background) process hits the event, when a specific error condition is raised or when a specific function is in the call stack:

Finally, the action keyword defines what to do when the event has been hit:

You can get more details about some actions by running the doc command for the library.action:

You can trace and set actions for Oracle kernel components (if you don't know exact function name which you want to trace). 

The following command would apply the actions query_block_dump, processstate dump and call stack dump only when executing code in RDBMS.SQL_Transform module (the query transformation engine) and only when the SQL ID executed is 32cqz71gd8wy3. Disk=high allows tracing to disk (if that component is able to trace anything).

You can check what sub-components are there under the SQL_Transform component (and you can trace each of these individually if you like):

All (registered) components in Oracle kernel can be listed like this: