Tracing PX session with a 10046 event or sql_trace (Doc ID 242374.

1)
***Checked for relevance on 30-April-2010***

PURPOSE
-------

This article explains what you will get if you use sql_trace or
the 10046 event to trace a parallel running query.

SCOPE & APPLICATION

-------------------

Support Analysts

Tacing session with 10046 event

-------------------------------
Tracing from 10046 is useful to show the SQL that is executed by the
parallel slaves. The advantage of using the 10046 event is that extra
details in output to the trace file depending on the level specified
with the event. Like wait event of the query coordinator and the parallel slaves.
For details about levels and syntax of the 10046 refer to
NOTE:21154.1 EVENT: 10046 "enable SQL statement tracing (including binds/waits)"

Tracing a session with a 10046 event when parallel exceution is used,

generates more than 1 trace file. You get a trace file for the QC
(query coordinator) and the query slaves QS that are involved in the query.

The slaves are only traced when you use a

alter session set events '10046 trace name context forever, level ...';
before you start the parallel query.

If you start tracing with oradebug or dbms_system.set_ev the event is not

send to the slaves. So they do not write a trace file.

Difference between QC and slave traces

======================================

Query coordinator(QC) parses the query and determines the degree of parallelism. QC
controls the query and sends instructions to the PQ slaves. QC produces the
final output to the user. The QC splits this SQL statement and makes new
'smaller' SQL statement from the original one and sends this to the
query slaves.

This means the original SQL command from the user will not be exectued. We
only execute the new small parts. This changes in 10g where all slaves
work on the original SQL command and we not create new smaller SQL commands
for the slaves.

It is possible to have more than one slave sets depending on the complexity of
the query. Simple query like 'select * from emp' run in prallel will use
one slave set - just to scan the table. Whereas query with sorting operations
will have two slave sets.
Enabling 10046 would create a trace file for each slave and the QC.

When we trace a session with 10046 event or sql_trace each slave

create a trace file where with the relevant information.
You find the trace files in the background_dump_dest or in the user_dump_dest.
It can happen that the trace for the QC is in the user_dump_dest and the
traces file for the slaves is in the background_dump_dest.

In 8i and maybe in early 9i version you do not see any trace file.
This is caused by a internal bug.

An example
----------

THe user execute the following SQL in parallel.

SELECT /*+ PARALLEL(e) PARALLEL(d) */ dname, MAX(sal), AVG(sal)
FROM emp e, dept d
WHERE e.deptno = d.deptno
GROUP BY dname;

Breakdown of the slave SQL commands, that will be executed

1 - SELECT /*+ CIV_GB */ A1.C0,AVG(SYS_OP_CSR(A1.C1,0)),

MAX(SYS_OP_CSR(A1.C1,1))
FROM :Q490001 A1
GROUP BY A1.C0

2 - SELECT /*+ PIV_GB */ A1.C1 C0,SYS_OP_MSR(AVG(A1.C0),MAX(A1.C0)) C1

FROM ( SELECT /*+ ORDERED NO_EXPAND USE_HASH(A3) */ A2.C1 C0,A3.C1 C1
FROM (SELECT /*+ NO_EXPAND ROWID(A4) */ A4."DEPTNO" C0,A4."SAL" C1
FROM "EMP" PX_GRANULE(0, BLOCK_RANGE, DYNAMIC) A4
) A2, :Q490000 A3
WHERE A2.C0=A3.C0
) A1
GROUP BY A1.C1

3 - SELECT /*+ NO_EXPAND ROWID(A1) */ A1."DEPTNO" C0,A1."DNAME" C1

FROM "DEPT" PX_GRANULE(0,BLOCK_RANGE, DYNAMIC) A1

The last three statements will be executed, but not the original one.

In 9i Release 2 you can see the slave information when you explian a statement
and then display the execution plan with the command:

select * from table(dbms_xplan.display('PLAN_TABLE',null,'ALL'));

See Note:236026.1 Ext/Pub Display Execution Plans with dbms_xplan.display

In older version you can see the Slave SQL statement when you use autotrace.