在并行执行SQL的情况下，利用SQL跟踪来调优我们的查询变得多少更困难了些。这是因为参与并行执行的每个进程都有它自己的跟踪文件。此外，因为这些进程是在所有SQL和会话中共享的，所以跟踪文件中除了我们感兴趣的数据，还包含有其它SQL和会话的跟踪数据。

　　表 13-1 并行数据流标识

　　然而，通过有点令人费解的过程，我们是可以跟踪并行执行的。下面是操作步骤：

　　利用“DBMS_SESSION.SET_ IDENTIFIER”在你的会话中设定唯一的客户端标识。

　　利用“DBMS_MONITOR.CLIENT_ ID_TRACE_ENABLE”对该客户端标识启用跟踪。

　　运行你的并行SQL。

　　利用“trcsess ”工具创建新的跟踪文件，其中只包含你客户端标识的条目。

　　像往常一样分析新的跟踪文件。

　　下面我们展示了步骤1，步骤2和步骤3：

　　下面我们执行步骤4和步骤5：

　　合并的跟踪文件现在不仅准确地反映了我们调用会话的活动，而且反映了执行该查询涉及的所有并行服务器进程。

　　要跟踪并行执行，请设置一个客户端标识，然后利用“trcsess ”工具来把该客户端标识对应的跟踪记录提取到单个文件中。

　　我们还可以利用“_px_trace”实现对并行服务器活动的高级跟踪。例如：

　　ALTER SESSION SET "_px_trace"="compilation","execution","messaging";

　　10391事件还可以被用来转储关于并行服务器分配的信息：

　　ALTER SESSION SET EVENTS '10391 trace name context forever, level 128';

　　这些事件的产生都非常隐性，有时会有一大堆输出，可能应该只在所有其它技术都不能清楚分析并行执行时才使用。