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