11g allows definition of tracing by SQL_ID as well.
Here is an example.
Given a particular SQL that has been executed in the past, which we've identified as :
We could use either ALTER SESSION (from the same session) or ALTER SYSTEM (from another session, to trace all sessions) to enable tracing specifically for this SQL alone.
(note : The options for "plan_stat" are "never", "first_execution", "all_executions"). This allows us to capture execution plan statistics.
Once I have enabled SQL-specific tracing, it is not limited to a session but can run across all sessions that execute the SQL. Even if I execute other SQLs from the same session that executed this SQL, the other SQLs are *not* traced.
Thus, I started another session that executed :
Tracing is disabled with :
Thus, just as in the previous post where I demonstrated tracing by module and action, we can enable tracing for a specific SQL.
.
.
.
Here is an example.
Given a particular SQL that has been executed in the past, which we've identified as :
SQL> select sql_id, sql_text, executions from v$sql where sql_id='06d4jjswswagq'; SQL_ID SQL_TEXT EXECUTIONS ------------- ------------------------------------------------------------------------------------- ---------- 06d4jjswswagq select department_id, sum(salary) from hr.employees group by department_id order by 1 1 SQL>
We could use either ALTER SESSION (from the same session) or ALTER SYSTEM (from another session, to trace all sessions) to enable tracing specifically for this SQL alone.
SQL> connect system/oracle Connected. SQL> alter system set events 'sql_trace [sql:06d4jjswswagq] wait=true, plan_stat=all_executions'; System altered. SQL>
(note : The options for "plan_stat" are "never", "first_execution", "all_executions"). This allows us to capture execution plan statistics.
Once I have enabled SQL-specific tracing, it is not limited to a session but can run across all sessions that execute the SQL. Even if I execute other SQLs from the same session that executed this SQL, the other SQLs are *not* traced.
Thus, I started another session that executed :
SQL> select department_id, sum(salary) from hr.employees group by department_id order by 1;
DEPARTMENT_ID SUM(SALARY)
------------- -----------
10 4400
20 19000
30 24900
40 6500
50 156400
60 28800
70 10000
80 304500
90 58000
100 51608
110 20308
DEPARTMENT_ID SUM(SALARY)
------------- -----------
7000
12 rows selected.
SQL> select count(*) from hr.employees;
COUNT(*)
----------
107
SQL> select count(*) from hr.departments;
COUNT(*)
----------
27
SQL>
The trace file only captured the target SQL. The other two SQLs were *not* in the trace file. Tracing is not bound to a session, so if you have multiple sessions executing the target SQL, each session creates a trace file.Tracing is disabled with :
SQL> alter system set events 'sql_trace [sql:06d4jjswswagq] off'; System altered. SQL>
Thus, just as in the previous post where I demonstrated tracing by module and action, we can enable tracing for a specific SQL.
.
.
.
No comments:
Post a Comment