10046事件和sql_trace
来源：互联网 发布：时代软件 编辑：程序博客网 时间：2024/05/22 12:22
一. SQL_TRACE
当SQL语句出现性能问题时，我们可以用SQL_TRACE来跟踪SQL的执行情况，通过跟踪，我们可以了解一条SQL或者PL/SQL包的运行情况，SQL_TRACE命令会将SQL执行的整个过程输出到一个trace文件中，我们可以读这个trace 文件来了解在这个SQL执行过程中Oracle 都做了哪些操作。
可以通过sql命令启动SQL_TRACE，或者在初始化参数里面。
SQL>alter session set sql_trace=true;
或者
SQL> alter database set sql_trace=true;
这两条命令的区别：
在session级别设置，只对当前session进行跟踪，在实例级别，会对实例上所有的SQL做跟踪，这种方式跟踪的SQL太多，代价是非常大的，所有很少用。
如果是在初始化文件里面设置，只需要在参数文件里添加一个sql_trace 参数即可。
示例：
1.确定的trace文件。
1.1 通过设置trace 文件标识
SQL> alter session set tracefile_identifier='jscntest';
Session altered.
会话已更改。
设置标识的目的就是方便我们查找生成的trace文件。我们只需要在trace目录查找文件名里带有标识的文件即可。 在Oracle 10g中，SQL_TRACE生成的trace文件默认路劲是$ORACLE_BASE/admin/SID/udump.
到了11g，trace 默认路径在：$ORACLE_BASE/diag/rdbms/orcl/orcl/trace目录下.
1.2直接用如下SQL直接查出，当前的trace文件名。
SQL> SELECT d.VALUE || '/' || LOWER(RTRIM(i.INSTANCE, CHR(0))) || '_ora_' ||
2 p.spid || '.trc' AS "trace_file_name"
3 FROM (SELECT p.spid
4 FROM v$mystat m, v$session s, v$process p
5 WHERE m.statistic# = 1
6 AND s.SID = m.SID
7 AND p.addr = s.paddr) p,
8 (SELECT t.INSTANCE
9 FROM v$thread t, v$parameter v
10 WHERE v.NAME = 'thread'
11 AND (v.VALUE = 0 OR t.thread# = TO_NUMBER(v.VALUE))) i,
12 (SELECT VALUE FROM v$parameter WHERE NAME = 'user_dump_dest') d;
trace_file_name
--------------------------------------------------------------------------------
2.启动SQL_TRACE
SQL> alter session set sql_trace=true;
Session altered.
3.进行相关事务操作
SQL> select * from t ;
4.关闭SQL_TRACE
SQL> alter session set sql_trace=false;
Session altered.
注意，这里是显示的关闭SQL_TRACE，在session级别，也可以直接退出SQLPLUS来终止SQL_TRACE。
二． TKPROF 工具
Oracle 官网的资料：
Using Application Tracing Tools
http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/sqltrace.htm#PFGRF010
SQL_TRACE 生成最原始的trace文件的可读性比较差，所以通常我们使用tkprof 工具来处理trace文件。 Tkprof 工具是Oracle 自带的一个工具，用于处理原始的trace文件，它的作用主要是合并汇总trace文件中的一些项，规范化文件的格式，使文件更具有可读性。
注意：tkprof 工具只能用在处理SQL_TRACE和10046事件产生的trace，其他事件如10053不能处理。
Tkprof 是系统级别的，直接在系统下执行即可。先看一下tkprof的帮助文档：
[oracle@jscn-db ~]$ tkprof
Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=schema.tablename Use 'schema.tablename' with 'explain=' option.
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN.
print=integer List only the first 'integer' SQL statements.
aggregate=yes|no
insert=filename List SQL statements and data inside INSERT statements.
sys=no TKPROF does not list SQL statements run as user SYS.
record=filename Record non-recursive statements found in the trace file.
waits=yes|no Record summary for any wait events found in the trace file.
sort=option Set of zero or more of the following sort options:
prscnt number of times parse was called
prscpu cpu time parsing
prsela elapsed time parsing
prsdsk number of disk reads during parse
prsqry number of buffers for consistent read during parse
prscu number of buffers for current read during parse
prsmis number of misses in library cache during parse
execnt number of execute was called
execpu cpu time spent executing
exeela elapsed time executing
exedsk number of disk reads during execute
exeqry number of buffers for consistent read during execute
execu number of buffers for current read during execute
exerow number of rows processed during execute
exemis number of library cache misses during execute
fchcnt number of times fetch was called
fchcpu cpu time spent fetching
fchela elapsed time fetching
fchdsk number of disk reads during fetch
fchqry number of buffers for consistent read during fetch
fchcu number of buffers for current read during fetch
fchrow number of rows fetched
userid userid of user that parsed the cursor
这个帮助对tkprof工具的参数做了说明。下面解释主要参数表示的含义
2.1 explain=user/password
在trace文件中输入SQL的执行计划，需要注意的是，如果不使用explain，在trace 文件中我们看到的是SQL实际的执行路劲。 如果使用了explain，tkprof在trace文件中不但输入SQL的实际执行路径，还会生成该SQL的执行计划。
2.2 sys=no
如果设置为yes，在trace 文件中将输入所有的SYS用户的操作，也包含用户SQL语句引发的递归SQL。
如果为no，则不输出这些信息。
不过默认情况下是yes，实际上设置为no后，trace文件具有更佳的可读性，因此一般在用tkprof工具时都手工的把该参数设置为no。
2.3 aggregate=yes|no
默认情况下，tkprof工具将所有相同的SQL在输入文件中做合并，如果设置为no，则分别列出每个SQL的信息。一般合并后看起来比较简洁，如果需要查看每一个SQL单独的信息，可以把aggregate设置为no。
[oracle@jscn-db udump]$ tkprof jscn_ora_20448_jscntest.trc jscntest.txt sys=no
TKPROF: Release 10.2.0.4.0 - Production on Sat Dec 10 14:24:13 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: jscn_ora_20448_jscntest.trc
Sort options: default
********************************************************************************
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
********************************************************************************
# 以上文件头信息描述了tkprof的版本信息，以及报告中一些列的含义，在下面的报告中，每一条SQL都包含了这条SQL执行过程的所有信息，对于
任何一条SQL，都应该至少包括3个步骤，对于下面call列。
*分析（Parse）：SQL分析阶段
*执行（Execute）：SQL执行阶段
*数据提取（Fetch）：数据的提取阶段
横向的列除了call（调用）之外，还包括以下信息：
* count ：计数器，表示当前的操作被执行多少次。
* cpu ：当前的操作消耗cpu的时间（单位秒）。
* elapsed ：当前操作一共用时多少（包括cpu和等待时间）
* disk ：当前操作的物理读（磁盘i/o次数）
* query ：当前操作一致性读取方式读取的数据块数（通常是查询使用的方式）
* current ：当前操作的current的方式读取的数据块数（通常是修改数据使用的方式）
* rows ：当前操作处理的数据记录数。
我们看到这个SQL，我们需要注意一下，这条SQL其实就是CBO做动态采样的SQL语句，如果我们看到这条sql语句，就知道这里使用了
动态采样（另一个比较重要的信息就是这个表可能没有做分析）：
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T") FULL("T") NO_PARALLEL_INDEX("T") */ :"SYS_B_2"
AS C1, :"SYS_B_3" AS C2 FROM "T" SAMPLE BLOCK (:"SYS_B_4" , :"SYS_B_5")
SEED (:"SYS_B_6") "T") SAMPLESUB
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 57 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 57 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60 (recursive depth: 1)
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=57 pr=0 pw=0 time=1876 us)
3811 TABLE ACCESS SAMPLE T (cr=57 pr=0 pw=0 time=7673 us)
********************************************************************************
下面这个才是我们真正需要的信息，我们执行那条sql的trace信息：
select *
from
t
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.04 0 84 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 67 0.00 0.00 0 79 0 991
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 69 0.01 0.04 0 163 0 991
我们看到，这条sql语句被分析了1次，执行了1次，数据提取了67次（数据提取不一定是一次就能提取完成的）。
其中cpu消耗是0.01秒，总耗时0.04秒，物理读取了0数据块(都在内存中)，一致读取163数据块，没有current（通常是update操作是会发生），一共提取数据记录为991行。
让我们继续看
Misses in library cache during parse: 1 -----shared pool中没有命中，说明这是一次硬解析，如果是软软分析，软分析这里为0.
Optimizer mode: ALL_ROWS -----当前优化器模式CBO ALL_ROWS
Parsing user id: 60 -----分析用户的ID
下面是这条sql语句的具体执行计划和执行消耗的资源信息。
这里要注意，这个计划里面信息不是CBO根据表分析数据估算出的数值，而是SQL语句执行过程中消耗的资源信息，其中：
Rows -----当前操作返回实际返回的记录数。
Row Source Operation -----行源操作，表示当前操作的数据访问方式
cr --(consistent read)，一致性方式读取的数据块，相当于query 的Fetch步骤。
pr --(physcical read)， 物理读取的数据块，相当于disk列上的Fetch步骤的值。
pw --(physcical wirte)，物理写
time --当前在操作执行的时间。
Rows Row Source Operation
------- ---------------------------------------------------
991 TABLE ACCESS FULL T (cr=79 pr=0 pw=0 time=1027 us)
下面我们再分析一下sql_trace期间所有的非递归sql语句（OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS）的执行信息统计汇总。
那什么叫递归sql呢？递归sql语句是执行一条sql语句衍生出执行一些其他的sql，这些衍生出来的sql叫做递归sql语句，比如Oracle执行一条我们这条sql：
select * from t where rownum<200
需要对这条sql语句进行分析，需要读取一些数据字典来获取相关的信息，比如：是否有权限、对象是否存在、对象的存储信息等。这些sql称为递归sql语句。
下面是非递归sql语句
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 18 0.01 0.01 0 3 0 0
Execute 18 0.00 0.00 0 0 0 9
Fetch 8 0.00 0.00 0 633 0 205
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 44 0.02 0.02 0 636 0 214
Misses in library cache during parse: 4
下面部分是所有递归的sql语句的信息统计
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 3 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 3 0.00 0.00 0 219 0 3
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 9 0.01 0.01 0 219 0 3
Misses in library cache during parse: 2
Misses in library cache during execute: 2
2.5 查看trace 文件
上面只是一个结果集，如果要深入分析sql，想确切地知道sql语句的每一步的执行是如何操作的，就需要分析原始的trace文件，这个trace文件尽管没有tkprof工具处理后的
易读，但是它能够让你确切地知道sql在哪个点在做什么，以及sql是如何工作的，这对于sql语句的执行过程是很有帮助，所以我们仍需要介绍一下它。
1）文件头部
/oracle/ora10/admin/jscn/udump/jscn_ora_19491_jscntest.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/ora10/product
System name: Linux
Node name: IM-8-201
Release: 2.6.18-238.el5
Version: #1 SMP Thu Jan 13 15:51:15 EST 2011
Machine: x86_64
Instance name: jscn
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 19491, image: oracle@IM-8-201
*** 2011-12-10 14:34:38.401
*** ACTION NAME:(Command Window - New) 2011-12-10 14:34:38.401
*** MODULE NAME:(PL/SQL Developer) 2011-12-10 14:34:38.401
*** SERVICE NAME:(jscn) 2011-12-10 14:34:38.401
*** SESSION ID:(152.29) 2011-12-10 14:34:38.401
上面是头部分，介绍数据库相关情况。
2）文件里面信息
*** 2011-12-10 15:16:27.852
=====================
PARSING IN CURSOR #3 len=37 dep=0 uid=45 oct=3 lid=45 tim=1292481958021890 hv=2693439083 ad='75513ba0'
select * from t where object_id=100
END OF STMT
PARSE #3:c=6999,e=7289,p=0,cr=74,cu=0,mis=1,r=0,dep=0,og=1,tim=1292481958021885
EXEC #3:c=0,e=19,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1292481958021959
FETCH #3:c=6999,e=6460,p=0,cr=626,cu=0,mis=0,r=1,dep=0,og=1,tim=1292481958029285
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=46208 op='TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=6443 us)'
=====================
这个文件的可读性要差很多。 对这里面的一些参数做些说明：
PARSING IN CURSOR 部分：
Len: 被解析SQL的长度
Dep: 产生递归SQL的深度
Uid：user id
Otc: Oracle command type 命令的类型
Lid: 私有用户id
Tim：时间戳
Hv： hash value
Ad：SQL address
PARSE,EXEC,FETCH 部分
C: 消耗的CPU time
E：elapsed time 操作的用时
P: physical reads 物理读的次数
Cr: consistent reads 一致性方式读取的数据块
Cu：current 方式读取的数据块
Mis：cursor misss in cache 硬分析次数
R: -rows 处理的行数
Dep: depth 递归SQL的深度
Og： optimizer goal 优化器模式
Tim：timestamp时间戳
STATS 部分：
Id: 执行计划的行源号
Cnt：当前行源返回的行数
Pid：当前行源号的父号
Pos：执行计划中的位置
Obj：当前操作的对象id（如果当前行原始一个对象的话）
Op：当前行源的数据访问操作
3、10046 事件
10046 事件主要用来跟踪SQL语句，它并不是ORACLE 官方提供给用户的命令，在官方文档上也找不到事件的说明信息。 但是用的却比较多，因为10046事件获取SQL的信息比SQL_TRACE 更多。 更有利于我们对SQL的判断。
10046 事件按照收集信息内容，可以分成4个级别：
Level 1： 等同于SQL_TRACE 的功能
Level 4： 在Level 1的基础上增加收集绑定变量的信息
Level 8： 在Level 1 的基础上增加等待事件的信息
Level 12：等同于Level 4+Level 8, 即同时收集绑定变量信息和等待事件信息。
1、让我们看一个列子，这里列子级别为：Level 4
SQL> create table t as select * from dba_objects;
Table created
SQL> exec dbms_stats.gather_table_stats(user,'t');
PL/SQL procedure successfully completed
--设置10046事件的级别为4
SQL> alter session set events '10046 trace name context forever,level 4';
Session altered
--定义2个变量x，y，然后让查询绑定这两个变量
SQL> var x number;
SQL> var y varchar2;
SQL> exec :x:=20
PL/SQL procedure successfully completed
x
---------
20
SQL> exec :y:='T';
PL/SQL procedure successfully completed
y
---------
T
SQL> select a.object_id,a.object_name from t a where a.object_id=:x or a.object_name=:y;
OBJECT_ID OBJECT_NAME
---------- --------------------------------------------------------------------------------
20 ICOL$
46210 T
--关闭10046事件
SQL> alter session set events '10046 trace name context off';
Session altered
查看trace文件
=====================
PARSING IN CURSOR #19 len=84 dep=0 uid=45 oct=3 lid=45 tim=1292486987236823 hv=54953670 ad='7579a660'
select a.object_id,a.object_name from t a where a.object_id=:x or a.object_name=:y
END OF STMT
PARSE #19:c=0,e=420,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1292486987236818
BINDS #19:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=2b6b3a0a36a8 bln=22 avl=02 flg=05
value=20
Bind#1
oacdty=01 mxl=4000(3000) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=01 csi=873 siz=4000 off=0
kxsbbbfp=2b6b3a172be8 bln=4000 avl=01 flg=05
value="T"
EXEC #19:c=2000,e=1664,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1292486987238546
FETCH #19:c=8999,e=9217,p=0,cr=626,cu=0,mis=0,r=2,dep=0,og=1,tim=1292486987248173
STAT #19 id=1 cnt=2 pid=0 pos=1 obj=46210 op='TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=9190 us)'
=====================
从上面可以看出Bind#0、Bind#1为第一个、和第二个绑定变量的类容。要说明的是如果tkprof之后的文件是看不到绑定变量里面的值。
下面就是格式化以后的文件
********************************************************************************
select a.object_id,a.object_name
from
t a where a.object_id=:x or a.object_name=:y
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.01 0.01 0 1252 0 4
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 6 0.02 0.02 0 1252 0 4
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
------- ---------------------------------------------------
2 TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=9190 us)
********************************************************************************
2、Level 8 级别
Level 8里面没有绑定变量的值，但是比sql_trace增加了等待事件的信息：
=====================
PARSING IN CURSOR #6 len=61 dep=0 uid=45 oct=47 lid=45 tim=1292487701756113 hv=356401299 ad='7553dc38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #6:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1292487701756108
BINDS #6:
kkscoacd
Bind#0
oacdty=01 mxl=4000(3000) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=01 csi=873 siz=4000 off=0
kxsbbbfp=2b6b3a172be8 bln=4000 avl=00 flg=05
EXEC #6:c=0,e=168,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1292487701756345
PARSE #19:c=0,e=8,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1292487701756862
EXEC #19:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1292487701756970
*** 2011-12-10 17:05:14.563
WAIT #19: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=46210 tim=1292488197816064
WAIT #19: nam='SQL*Net message from client' ela= 22170 driver id=1413697536 #bytes=1 p3=0 obj#=46210 tim=1292488197838426
=====================
SQL*Net message to client ----客户端等待服务器端的反馈信息
SQL*Net message from client ---服务器等待客户端的请求
Level 12，这两个都有了。
3.1 对当前session 使用10046事件
SQL>alter session set events '10046 trace name context forever, level 12'; --启动10046事件
执行相关事务
SQL>alter session set events '10046 trace name context off'; -- 关闭10046事件
该事件收集的信息也是放在trace文件中，查看trace文件的方法，参考第二节：TKPROF 工具。
3.2对其他的会话进行跟踪
之前说的都是对当前session进行跟踪，在生产环境中，可能需要对其他session进行跟踪，有如下2种方法：
3.2.1 用SQL_TRACE跟踪
SQL> select sid,serial# from v$session where SID=1021 ;
SID SERIAL#
---------- ----------
2 ltrim(to_char(a.spid,'fm99999')) || '.trc'
3 from v$process a, v$session b, v$parameter c, v$thread c
4 where a.addr = b.paddr
5 and b.sid = 1021 and b.serial#=10
6 and c.name = 'user_dump_dest'
7 ;
C.VALUE||'/'||INSTANCE||'_ORA_
--------------------------------------------------------------------------------
/oracle/ora10g/admin/jscn/udump/jscn1_ora_30142.trc
/oracle/ora10g/admin/jscn/udump/jscn2_ora_30142.trc
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,true);
begin dbms_system.set_sql_trace_in_session(1021 ,10,true); end;
ORA-06550: line 2, column 7:
PLS-00201: identifier 'DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION' must be declared
ORA-06550: line 2, column 7:
PL/SQL: Statement ignored
[oracle@IM-8-201 udump]$ sqlplus / as sysdba @/oracle/ora10/product/rdbms/admin/prvtutil.plb
View created.
Type created.
Type created.
Package body created.
Package created.
Package body created.
SQL> grant execute on dbms_system to test;
Grant succeeded.
--test用户执行
SQL> create synonym dbms_system for sys.dbms_system;
Synonym created
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,true); -- 启动SQL_TRACE
PL/SQL 过程已成功完成。
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,false); -- 关闭SQL_TRACE
PL/SQL 过程已成功完成。
3.2.2 使用10046 事件跟踪
SQL> exec dbms_monitor.session_trace_enable(1021,10,waits=>true,binds=>true); -- 启动trace
PL/SQL 过程已成功完成。
SQL> exec dbms_monitor.session_trace_disable(1021,10); -- 关闭trace
PL/SQL 过程已成功完成。
注意：
如果一条SQL语句中包含了通过DBLINK进行的数据操作，我们想对这条SQL进行trace跟踪，在本地只能够trace到本地执行的SQL信息，而对于远程的SQL语句，由于它运行在远端的数据库上，我们要获得它的信息，需要到远端的数据库上，找到运行这条SQL语句的session，然后对它做Trace。 另外，这条SQL语句的执行计划也只能从远端数据库上捕获到。
总之，当SQL语句操作出现性能问题时，我们可以用SQL_TRACE 或者10046事件进行跟踪是最合适的。 如果是数据库整体性能下降，就需要使用statspack或者AWR对数据库进行分析。
3.3 使用oradebug 生成10046 事件
SYS@anqing1(rac1)> oradebug setmypid
SYS@anqing1(rac1)> oradebug event 10046trace name context forever,level 8;
SYS@anqing1(rac1)> oradebug event 10046trace name context off;
SYS@anqing1(rac1)> oradebugtracefile_name
/u01/app/oracle/admin/anqing/udump/anqing1_ora_17800.trc
当SQL语句出现性能问题时，我们可以用SQL_TRACE来跟踪SQL的执行情况，通过跟踪，我们可以了解一条SQL或者PL/SQL包的运行情况，SQL_TRACE命令会将SQL执行的整个过程输出到一个trace文件中，我们可以读这个trace 文件来了解在这个SQL执行过程中Oracle 都做了哪些操作。
可以通过sql命令启动SQL_TRACE，或者在初始化参数里面。
SQL>alter session set sql_trace=true;
或者
SQL> alter database set sql_trace=true;
这两条命令的区别：
在session级别设置，只对当前session进行跟踪，在实例级别，会对实例上所有的SQL做跟踪，这种方式跟踪的SQL太多，代价是非常大的，所有很少用。
如果是在初始化文件里面设置，只需要在参数文件里添加一个sql_trace 参数即可。
示例：
1.确定的trace文件。
1.1 通过设置trace 文件标识
SQL> alter session set tracefile_identifier='jscntest';
Session altered.
会话已更改。
设置标识的目的就是方便我们查找生成的trace文件。我们只需要在trace目录查找文件名里带有标识的文件即可。 在Oracle 10g中，SQL_TRACE生成的trace文件默认路劲是$ORACLE_BASE/admin/SID/udump.
到了11g，trace 默认路径在：$ORACLE_BASE/diag/rdbms/orcl/orcl/trace目录下.
1.2直接用如下SQL直接查出，当前的trace文件名。
- SELECT d.VALUE || '/' || LOWER(RTRIM(i.INSTANCE, CHR(0))) || '_ora_' ||
- p.spid || '.trc' AS "trace_file_name"
- FROM (SELECT p.spid
- FROM v$mystat m, v$session s, v$process p
- WHERE m.statistic# = 1
- AND s.SID = m.SID
- AND p.addr = s.paddr) p,
- (SELECT t.INSTANCE
- FROM v$thread t, v$parameter v
- WHERE v.NAME = 'thread'
- AND (v.VALUE = 0 OR t.thread# = TO_NUMBER(v.VALUE))) i,
- (SELECT VALUE FROM v$parameter WHERE NAME = 'user_dump_dest') d;
SELECT d.VALUE || '/' || LOWER(RTRIM(i.INSTANCE, CHR(0))) || '_ora_' || p.spid || '.trc' AS "trace_file_name" FROM (SELECT p.spid FROM v$mystat m, v$session s, v$process p WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p, (SELECT t.INSTANCE FROM v$thread t, v$parameter v WHERE v.NAME = 'thread' AND (v.VALUE = 0 OR t.thread# = TO_NUMBER(v.VALUE))) i, (SELECT VALUE FROM v$parameter WHERE NAME = 'user_dump_dest') d;
SQL> SELECT d.VALUE || '/' || LOWER(RTRIM(i.INSTANCE, CHR(0))) || '_ora_' ||
2 p.spid || '.trc' AS "trace_file_name"
3 FROM (SELECT p.spid
4 FROM v$mystat m, v$session s, v$process p
5 WHERE m.statistic# = 1
6 AND s.SID = m.SID
7 AND p.addr = s.paddr) p,
8 (SELECT t.INSTANCE
9 FROM v$thread t, v$parameter v
10 WHERE v.NAME = 'thread'
11 AND (v.VALUE = 0 OR t.thread# = TO_NUMBER(v.VALUE))) i,
12 (SELECT VALUE FROM v$parameter WHERE NAME = 'user_dump_dest') d;
trace_file_name
--------------------------------------------------------------------------------
/oracle/ora10g/admin/jscn/udump/jscn_ora_20448.trc
2.启动SQL_TRACE
SQL> alter session set sql_trace=true;
Session altered.
3.进行相关事务操作
SQL> select * from t ;
4.关闭SQL_TRACE
SQL> alter session set sql_trace=false;
Session altered.
注意，这里是显示的关闭SQL_TRACE，在session级别，也可以直接退出SQLPLUS来终止SQL_TRACE。
二． TKPROF 工具
Oracle 官网的资料：
Using Application Tracing Tools
http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/sqltrace.htm#PFGRF010
SQL_TRACE 生成最原始的trace文件的可读性比较差，所以通常我们使用tkprof 工具来处理trace文件。 Tkprof 工具是Oracle 自带的一个工具，用于处理原始的trace文件，它的作用主要是合并汇总trace文件中的一些项，规范化文件的格式，使文件更具有可读性。
注意：tkprof 工具只能用在处理SQL_TRACE和10046事件产生的trace，其他事件如10053不能处理。
Tkprof 是系统级别的，直接在系统下执行即可。先看一下tkprof的帮助文档：
[oracle@jscn-db ~]$ tkprof
Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=schema.tablename Use 'schema.tablename' with 'explain=' option.
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN.
print=integer List only the first 'integer' SQL statements.
aggregate=yes|no
insert=filename List SQL statements and data inside INSERT statements.
sys=no TKPROF does not list SQL statements run as user SYS.
record=filename Record non-recursive statements found in the trace file.
waits=yes|no Record summary for any wait events found in the trace file.
sort=option Set of zero or more of the following sort options:
prscnt number of times parse was called
prscpu cpu time parsing
prsela elapsed time parsing
prsdsk number of disk reads during parse
prsqry number of buffers for consistent read during parse
prscu number of buffers for current read during parse
prsmis number of misses in library cache during parse
execnt number of execute was called
execpu cpu time spent executing
exeela elapsed time executing
exedsk number of disk reads during execute
exeqry number of buffers for consistent read during execute
execu number of buffers for current read during execute
exerow number of rows processed during execute
exemis number of library cache misses during execute
fchcnt number of times fetch was called
fchcpu cpu time spent fetching
fchela elapsed time fetching
fchdsk number of disk reads during fetch
fchqry number of buffers for consistent read during fetch
fchcu number of buffers for current read during fetch
fchrow number of rows fetched
userid userid of user that parsed the cursor
这个帮助对tkprof工具的参数做了说明。下面解释主要参数表示的含义
2.1 explain=user/password
在trace文件中输入SQL的执行计划，需要注意的是，如果不使用explain，在trace 文件中我们看到的是SQL实际的执行路劲。 如果使用了explain，tkprof在trace文件中不但输入SQL的实际执行路径，还会生成该SQL的执行计划。
2.2 sys=no
如果设置为yes，在trace 文件中将输入所有的SYS用户的操作，也包含用户SQL语句引发的递归SQL。
如果为no，则不输出这些信息。
不过默认情况下是yes，实际上设置为no后，trace文件具有更佳的可读性，因此一般在用tkprof工具时都手工的把该参数设置为no。
2.3 aggregate=yes|no
默认情况下，tkprof工具将所有相同的SQL在输入文件中做合并，如果设置为no，则分别列出每个SQL的信息。一般合并后看起来比较简洁，如果需要查看每一个SQL单独的信息，可以把aggregate设置为no。
2.4 查看第一节中生成的trace文件
这部分重点关注
[oracle@jscn-db udump]$ tkprof jscn_ora_20448_jscntest.trc jscntest.txt sys=no
TKPROF: Release 10.2.0.4.0 - Production on Sat Dec 10 14:24:13 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: jscn_ora_20448_jscntest.trc
Sort options: default
********************************************************************************
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
********************************************************************************
# 以上文件头信息描述了tkprof的版本信息，以及报告中一些列的含义，在下面的报告中，每一条SQL都包含了这条SQL执行过程的所有信息，对于
任何一条SQL，都应该至少包括3个步骤，对于下面call列。
*分析（Parse）：SQL分析阶段
*执行（Execute）：SQL执行阶段
*数据提取（Fetch）：数据的提取阶段
横向的列除了call（调用）之外，还包括以下信息：
* count ：计数器，表示当前的操作被执行多少次。
* cpu ：当前的操作消耗cpu的时间（单位秒）。
* elapsed ：当前操作一共用时多少（包括cpu和等待时间）
* disk ：当前操作的物理读（磁盘i/o次数）
* query ：当前操作一致性读取方式读取的数据块数（通常是查询使用的方式）
* current ：当前操作的current的方式读取的数据块数（通常是修改数据使用的方式）
* rows ：当前操作处理的数据记录数。
我们看到这个SQL，我们需要注意一下，这条SQL其实就是CBO做动态采样的SQL语句，如果我们看到这条sql语句，就知道这里使用了
动态采样（另一个比较重要的信息就是这个表可能没有做分析）：
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T") FULL("T") NO_PARALLEL_INDEX("T") */ :"SYS_B_2"
AS C1, :"SYS_B_3" AS C2 FROM "T" SAMPLE BLOCK (:"SYS_B_4" , :"SYS_B_5")
SEED (:"SYS_B_6") "T") SAMPLESUB
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 57 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 57 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60 (recursive depth: 1)
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=57 pr=0 pw=0 time=1876 us)
3811 TABLE ACCESS SAMPLE T (cr=57 pr=0 pw=0 time=7673 us)
********************************************************************************
下面这个才是我们真正需要的信息，我们执行那条sql的trace信息：
select *
from
t
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.04 0 84 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 67 0.00 0.00 0 79 0 991
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 69 0.01 0.04 0 163 0 991
我们看到，这条sql语句被分析了1次，执行了1次，数据提取了67次（数据提取不一定是一次就能提取完成的）。
其中cpu消耗是0.01秒，总耗时0.04秒，物理读取了0数据块(都在内存中)，一致读取163数据块，没有current（通常是update操作是会发生），一共提取数据记录为991行。
让我们继续看
Misses in library cache during parse: 1 -----shared pool中没有命中，说明这是一次硬解析，如果是软软分析，软分析这里为0.
Optimizer mode: ALL_ROWS -----当前优化器模式CBO ALL_ROWS
Parsing user id: 60 -----分析用户的ID
下面是这条sql语句的具体执行计划和执行消耗的资源信息。
这里要注意，这个计划里面信息不是CBO根据表分析数据估算出的数值，而是SQL语句执行过程中消耗的资源信息，其中：
Rows -----当前操作返回实际返回的记录数。
Row Source Operation -----行源操作，表示当前操作的数据访问方式
cr --(consistent read)，一致性方式读取的数据块，相当于query 的Fetch步骤。
pr --(physcical read)， 物理读取的数据块，相当于disk列上的Fetch步骤的值。
pw --(physcical wirte)，物理写
time --当前在操作执行的时间。
Rows Row Source Operation
------- ---------------------------------------------------
991 TABLE ACCESS FULL T (cr=79 pr=0 pw=0 time=1027 us)
下面我们再分析一下sql_trace期间所有的非递归sql语句（OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS）的执行信息统计汇总。
那什么叫递归sql呢？递归sql语句是执行一条sql语句衍生出执行一些其他的sql，这些衍生出来的sql叫做递归sql语句，比如Oracle执行一条我们这条sql：
select * from t where rownum<200
需要对这条sql语句进行分析，需要读取一些数据字典来获取相关的信息，比如：是否有权限、对象是否存在、对象的存储信息等。这些sql称为递归sql语句。
下面是非递归sql语句
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 18 0.01 0.01 0 3 0 0
Execute 18 0.00 0.00 0 0 0 9
Fetch 8 0.00 0.00 0 633 0 205
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 44 0.02 0.02 0 636 0 214
Misses in library cache during parse: 4
下面部分是所有递归的sql语句的信息统计
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 3 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 3 0.00 0.00 0 219 0 3
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 9 0.01 0.01 0 219 0 3
Misses in library cache during parse: 2
Misses in library cache during execute: 2
2.5 查看trace 文件
上面只是一个结果集，如果要深入分析sql，想确切地知道sql语句的每一步的执行是如何操作的，就需要分析原始的trace文件，这个trace文件尽管没有tkprof工具处理后的
易读，但是它能够让你确切地知道sql在哪个点在做什么，以及sql是如何工作的，这对于sql语句的执行过程是很有帮助，所以我们仍需要介绍一下它。
1）文件头部
/oracle/ora10/admin/jscn/udump/jscn_ora_19491_jscntest.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/ora10/product
System name: Linux
Node name: IM-8-201
Release: 2.6.18-238.el5
Version: #1 SMP Thu Jan 13 15:51:15 EST 2011
Machine: x86_64
Instance name: jscn
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 19491, image: oracle@IM-8-201
*** 2011-12-10 14:34:38.401
*** ACTION NAME:(Command Window - New) 2011-12-10 14:34:38.401
*** MODULE NAME:(PL/SQL Developer) 2011-12-10 14:34:38.401
*** SERVICE NAME:(jscn) 2011-12-10 14:34:38.401
*** SESSION ID:(152.29) 2011-12-10 14:34:38.401
上面是头部分，介绍数据库相关情况。
2）文件里面信息
*** 2011-12-10 15:16:27.852
=====================
PARSING IN CURSOR #3 len=37 dep=0 uid=45 oct=3 lid=45 tim=1292481958021890 hv=2693439083 ad='75513ba0'
select * from t where object_id=100
END OF STMT
PARSE #3:c=6999,e=7289,p=0,cr=74,cu=0,mis=1,r=0,dep=0,og=1,tim=1292481958021885
EXEC #3:c=0,e=19,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1292481958021959
FETCH #3:c=6999,e=6460,p=0,cr=626,cu=0,mis=0,r=1,dep=0,og=1,tim=1292481958029285
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=46208 op='TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=6443 us)'
=====================
这个文件的可读性要差很多。 对这里面的一些参数做些说明：
PARSING IN CURSOR 部分：
Len: 被解析SQL的长度
Dep: 产生递归SQL的深度
Uid：user id
Otc: Oracle command type 命令的类型
Lid: 私有用户id
Tim：时间戳
Hv： hash value
Ad：SQL address
PARSE,EXEC,FETCH 部分
C: 消耗的CPU time
E：elapsed time 操作的用时
P: physical reads 物理读的次数
Cr: consistent reads 一致性方式读取的数据块
Cu：current 方式读取的数据块
Mis：cursor misss in cache 硬分析次数
R: -rows 处理的行数
Dep: depth 递归SQL的深度
Og： optimizer goal 优化器模式
Tim：timestamp时间戳
STATS 部分：
Id: 执行计划的行源号
Cnt：当前行源返回的行数
Pid：当前行源号的父号
Pos：执行计划中的位置
Obj：当前操作的对象id（如果当前行原始一个对象的话）
Op：当前行源的数据访问操作
3、10046 事件
10046 事件主要用来跟踪SQL语句，它并不是ORACLE 官方提供给用户的命令，在官方文档上也找不到事件的说明信息。 但是用的却比较多，因为10046事件获取SQL的信息比SQL_TRACE 更多。 更有利于我们对SQL的判断。
10046 事件按照收集信息内容，可以分成4个级别：
Level 1： 等同于SQL_TRACE 的功能
Level 4： 在Level 1的基础上增加收集绑定变量的信息
Level 8： 在Level 1 的基础上增加等待事件的信息
Level 12：等同于Level 4+Level 8, 即同时收集绑定变量信息和等待事件信息。
1、让我们看一个列子，这里列子级别为：Level 4
SQL> create table t as select * from dba_objects;
Table created
SQL> exec dbms_stats.gather_table_stats(user,'t');
PL/SQL procedure successfully completed
--设置10046事件的级别为4
SQL> alter session set events '10046 trace name context forever,level 4';
Session altered
--定义2个变量x，y，然后让查询绑定这两个变量
SQL> var x number;
SQL> var y varchar2;
SQL> exec :x:=20
PL/SQL procedure successfully completed
x
---------
20
SQL> exec :y:='T';
PL/SQL procedure successfully completed
y
---------
T
SQL> select a.object_id,a.object_name from t a where a.object_id=:x or a.object_name=:y;
OBJECT_ID OBJECT_NAME
---------- --------------------------------------------------------------------------------
20 ICOL$
46210 T
--关闭10046事件
SQL> alter session set events '10046 trace name context off';
Session altered
查看trace文件
=====================
PARSING IN CURSOR #19 len=84 dep=0 uid=45 oct=3 lid=45 tim=1292486987236823 hv=54953670 ad='7579a660'
select a.object_id,a.object_name from t a where a.object_id=:x or a.object_name=:y
END OF STMT
PARSE #19:c=0,e=420,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1292486987236818
BINDS #19:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=2b6b3a0a36a8 bln=22 avl=02 flg=05
value=20
Bind#1
oacdty=01 mxl=4000(3000) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=01 csi=873 siz=4000 off=0
kxsbbbfp=2b6b3a172be8 bln=4000 avl=01 flg=05
value="T"
EXEC #19:c=2000,e=1664,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1292486987238546
FETCH #19:c=8999,e=9217,p=0,cr=626,cu=0,mis=0,r=2,dep=0,og=1,tim=1292486987248173
STAT #19 id=1 cnt=2 pid=0 pos=1 obj=46210 op='TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=9190 us)'
=====================
从上面可以看出Bind#0、Bind#1为第一个、和第二个绑定变量的类容。要说明的是如果tkprof之后的文件是看不到绑定变量里面的值。
下面就是格式化以后的文件
********************************************************************************
select a.object_id,a.object_name
from
t a where a.object_id=:x or a.object_name=:y
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.01 0.01 0 1252 0 4
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 6 0.02 0.02 0 1252 0 4
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
------- ---------------------------------------------------
2 TABLE ACCESS FULL T (cr=626 pr=0 pw=0 time=9190 us)
********************************************************************************
2、Level 8 级别
Level 8里面没有绑定变量的值，但是比sql_trace增加了等待事件的信息：
=====================
PARSING IN CURSOR #6 len=61 dep=0 uid=45 oct=47 lid=45 tim=1292487701756113 hv=356401299 ad='7553dc38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #6:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1292487701756108
BINDS #6:
kkscoacd
Bind#0
oacdty=01 mxl=4000(3000) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=01 csi=873 siz=4000 off=0
kxsbbbfp=2b6b3a172be8 bln=4000 avl=00 flg=05
EXEC #6:c=0,e=168,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1292487701756345
PARSE #19:c=0,e=8,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1292487701756862
EXEC #19:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1292487701756970
*** 2011-12-10 17:05:14.563
WAIT #19: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=46210 tim=1292488197816064
WAIT #19: nam='SQL*Net message from client' ela= 22170 driver id=1413697536 #bytes=1 p3=0 obj#=46210 tim=1292488197838426
=====================
SQL*Net message to client ----客户端等待服务器端的反馈信息
SQL*Net message from client ---服务器等待客户端的请求
Level 12，这两个都有了。
3.1 对当前session 使用10046事件
SQL>alter session set events '10046 trace name context forever, level 12'; --启动10046事件
执行相关事务
SQL>alter session set events '10046 trace name context off'; -- 关闭10046事件
该事件收集的信息也是放在trace文件中，查看trace文件的方法，参考第二节：TKPROF 工具。
3.2对其他的会话进行跟踪
之前说的都是对当前session进行跟踪，在生产环境中，可能需要对其他session进行跟踪，有如下2种方法：
3.2.1 用SQL_TRACE跟踪
SQL> select sid,serial# from v$session where SID=1021 ;
SID SERIAL#
---------- ----------
1021 10
找出trace文件
- select c.value || '/' || instance || '_ora_' ||
- ltrim(to_char(a.spid,'fm99999')) || '.trc'
- from v$process a, v$session b, v$parameter c, v$thread c
- here a.addr = b.paddr
- and b.sid = 1021 and b.serial#=10
- and c.name = 'user_dump_dest'
select c.value || '/' || instance || '_ora_' || ltrim(to_char(a.spid,'fm99999')) || '.trc' from v$process a, v$session b, v$parameter c, v$thread c where a.addr = b.paddr and b.sid = 1021 and b.serial#=10 and c.name = 'user_dump_dest'SQL> select c.value || '/' || instance || '_ora_' ||
2 ltrim(to_char(a.spid,'fm99999')) || '.trc'
3 from v$process a, v$session b, v$parameter c, v$thread c
4 where a.addr = b.paddr
5 and b.sid = 1021 and b.serial#=10
6 and c.name = 'user_dump_dest'
7 ;
C.VALUE||'/'||INSTANCE||'_ORA_
--------------------------------------------------------------------------------
/oracle/ora10g/admin/jscn/udump/jscn1_ora_30142.trc
/oracle/ora10g/admin/jscn/udump/jscn2_ora_30142.trc
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,true);
begin dbms_system.set_sql_trace_in_session(1021 ,10,true); end;
ORA-06550: line 2, column 7:
PLS-00201: identifier 'DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION' must be declared
ORA-06550: line 2, column 7:
PL/SQL: Statement ignored
[oracle@IM-8-201 udump]$ sqlplus / as sysdba @/oracle/ora10/product/rdbms/admin/prvtutil.plb
View created.
Type created.
Type created.
Package body created.
Package created.
Package body created.
SQL> grant execute on dbms_system to test;
Grant succeeded.
--test用户执行
SQL> create synonym dbms_system for sys.dbms_system;
Synonym created
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,true); -- 启动SQL_TRACE
PL/SQL 过程已成功完成。
SQL> execute dbms_system.set_sql_trace_in_session(1021 ,10,false); -- 关闭SQL_TRACE
PL/SQL 过程已成功完成。
3.2.2 使用10046 事件跟踪
SQL> exec dbms_monitor.session_trace_enable(1021,10,waits=>true,binds=>true); -- 启动trace
PL/SQL 过程已成功完成。
SQL> exec dbms_monitor.session_trace_disable(1021,10); -- 关闭trace
PL/SQL 过程已成功完成。
注意：
如果一条SQL语句中包含了通过DBLINK进行的数据操作，我们想对这条SQL进行trace跟踪，在本地只能够trace到本地执行的SQL信息，而对于远程的SQL语句，由于它运行在远端的数据库上，我们要获得它的信息，需要到远端的数据库上，找到运行这条SQL语句的session，然后对它做Trace。 另外，这条SQL语句的执行计划也只能从远端数据库上捕获到。
总之，当SQL语句操作出现性能问题时，我们可以用SQL_TRACE 或者10046事件进行跟踪是最合适的。 如果是数据库整体性能下降，就需要使用statspack或者AWR对数据库进行分析。
3.3 使用oradebug 生成10046 事件
SYS@anqing1(rac1)> oradebug setmypid
SYS@anqing1(rac1)> oradebug event 10046trace name context forever,level 8;
SYS@anqing1(rac1)> oradebug event 10046trace name context off;
SYS@anqing1(rac1)> oradebugtracefile_name
/u01/app/oracle/admin/anqing/udump/anqing1_ora_17800.trc
- SQL_TRACE和10046事件
- 10046事件和sql_trace
- 10046事件和sql_trace
- oracle SQL_TRACE和10046事件
- 10046事件 sql_trace 启动和停止
- Sql_trace及10046事件
- sql_trace/10046事件数据库诊断
- SQL_Trace 和 10046 +
- SQL_Trace 和 10046 +
- 使用sql_trace/10046事件进行数据库诊断
- SQL_TRACE/10046事件如何使用，详细分析
- 使用SQL_Trace/10046事件进行数据库诊断
- 使用 SQL_TRACE/10046 事件进行数据库诊断
- 演示使用sql_trace和10046事件对其他会话进行跟踪，并给出trace结果
- 变量绑定和sql_trace
- sql_trace和tkprof工具
- SQL_TRACE
- sql_trace
- 基础的粒子群算法代码
- Whitespace is not allowed after end of MarkupExtension 解决办法
- 跟我学习GNU Emacs - 10
- 在MYSQL里 段错误 (core dumped)是什么原因？如何解决
- 用模拟退火算法解决0-1背包问题
- 10046事件和sql_trace
- 迭代法 详解 ,最大公约数和最小公倍数
- 【消息队列MQ】【Kafka&Jafka】design-2
- Spring3 Web MVC下的数据类型转换
- 如何让IOS应用从容地崩溃
- Reactor 模式的 JAVA NIO 多线程服务器
- apk文件签名之命令行法
- 计算机模拟四维水污染扩散模型
- Pregel: A System for Large-Scale Graph Processing【转】
