获取跟踪文件名称

跟踪的信息在user_dump_dest目录下可以找到或通过如下脚本获得文件名称（适用于Win环境，如果是unix需要做一定修改）

conn system/pwd

SELECT p1.value||'\'||p2.value||'_ora_'||p.spid||'.trc' filename

FROM

v$process p,

v$session s,

v$parameter p1,

v$parameter p2

WHERE p1.name = 'user_dump_dest'

AND p2.name = 'db_name'

AND p.addr = s.paddr

AND s.audsid = USERENV ('SESSIONID')

在unix的目录下

http://www.eygle.com/faq/script/gettrcnameunix.sql

有了正确而详细的诊断数据之后，你需要以摘要的形式对其进行查看，这有助于你以最快的速度做出响应。

Cmd tkprof path\xxx.prc xxx.txt

报告解读：

parse(分析)：在共享池中找到该查询（软分析）或者创建该查询的新计划（硬分析）

execute(执行)：执行查询的所有工作

fetch(提取)：显示select的提取工作，对于update，则没有内容

count(计数):执行的次数

cpu:此阶段cpu的耗时，以毫秒为单位

elapsed(占用时间):挂钟时间，如果大于cpu时间，则有等待时间

disk(磁盘)：执行物理I/O的次数

QUERY(查询):检索一致性执行的I/O次数

CURRENT(当前)：到当前多执行的逻辑I/O次数

ROW:此阶段被处理或者受到影响的行

如果一个UPDATE语句EXECUTE的QUERY,CURRENT，ROWS分别为2000 1000 500,表示这个语句访问了2000个块找到需要UPDATE的行记录，在UPDATE的时候只访问了1000个块，一共更新了500行。如果只获取很少的数据，而要访问了大量的块，表明SQL与需要优化了。

MISSES 缓存命中率：0 表示已经通过软分析

OPTIMIZER GOAL（优化程序目标）

执行计划：与前面的执行计划相比，增加了各个阶段涉及的行数

关闭

alter system set events '10046 trace name context off';

更好的方法是使用DBMS_SUPPORT包来激活扩展SQL跟踪：

dbms_support.start_trace(waits=>;true, binds=>;true)

/* code to be traced goes here */

dbms_support.stop_trace()

请注意DBMS_SUPPORT 没有文档说明，可能也不是数据库默认安装的一部分。要了解DBMS_SUPPORT的信息，请参考MetaLink ( metalink.oracle.com)。

跟踪别人的代码。如果你想跟踪没有读/写权限的代码，则激活扩展SQL跟踪就有点麻烦了。但也不会难很多。你首先要获得你想跟踪的会话的V$SESSION.SID和V$SESSION.SERIAL#值。然后使用下面的过程调用，可以设置所选会话的TIMED_STATISTICS和MAX_DUMP_FILE_SIZE参数：

dbms_system.set_bool_param_in_session(

sid =>; 42,

serial# =>; 1215,

parnam =>; 'timed_statistics',

bval =>; true)

dbms_system.set_int_param_in_session(

sid =>; 42,

serial# =>; 1215,

parnam =>; 'max_dump_file_size',

intval =>; 2147483647)

（对于Oracle8 8.1.6以前的版本，你可以用ALTER SYSTEM命令处理这些参数。）

接下来要激活跟踪。有几种方法可以采用，包括下面两个：

方法一是使用DBMS_SUPPORT：

dbms_support.start_trace_in_session(

sid =>; 42,

serial# =>; 1215,

waits =>; true,

binds =>; true)

/* code to be traced executes during this time window */

dbms_support.stop_trace_in_session(

sid =>; 42,

serial =>; 1215)

若想激活扩展SQL跟踪，请不要使用名为SET_SQL_TRACE_IN_SESSION的DBMS_SUPPORT过程。该过程不允许在跟踪文件中指定等待和绑定的数据。

第二种方法更为精致，但在Oracle数据库10g之前的版本中并不支持这种方法。DBMS_MONITOR包的引入解决了许多复杂诊断数据收集问题，这些问题是由连接共享和多线程操作所引起的。你可以在Oracle数据库10g中指定要跟踪的服务、模块或行动，而不指定要跟踪的Oracle数据库会话：

dbms_monitor.serv_mod_act_trace_enable(

service_name =>; 'APPS1',

module_name =>; 'PAYROLL',

action_name =>; 'PYUGEN',

waits =>; true,

binds =>; true,

instance_name =>; null)

/* code to be traced executes during this time window */

dbms_monitor.serv_mod_act_trace_disable(

service_name =>; 'APPS1',

module_name =>; 'PAYROLL',

action_name =>; 'PYUGEN')

利用DBMS_MONITOR包，Oracle可为要跟踪的特定的业务操作提供完全支持激活或停止诊断数据收集的方法。

在PL/SQL中,由于不能执行alter session,可以使用

　　dbms_session.set_sql_trace(TRUE);

　　必须安装DBMS_SESSION包，并"直接"赋给用户alter session的权限。

当我们使用sql

For Unix:

$ sqlplus "/ as sysdba"