10046事件跟踪会话sql

背景知识:

10046 事件按照收集信息内容,可以分成4个级别:

Level 1: 等同于SQL_TRACE 的功能

Level 4: 在Level 1的基础上增加收集绑定变量的信息

Level 8: 在Level 1 的基础上增加等待事件的信息

Level 12:等同于Level 4+Level 8, 即同时收集绑定变量信息和等待事件信息。

一: 跟踪当前会话sql

1. sys用户给执行跟踪dblink用户授权
SQL> grant alter session to dblink;

Grant succeeded.

2. 返回dblink用户操作
SQL> show user;
USER is "DBLINK"

3. 查询sid,serial#
SQL> select sid,serial# from v$session where username=‘DBLINK‘;

SID SERIAL#
---------- ----------
45 14

4. 查询当前用户的trace文件
SQL> select * from v$diag_info where name like ‘Default%‘;

INST_ID NAME
---------- ----------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
1 Default Trace File
/home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2823.trc

5. 启动10046事件
SQL> alter session set events ‘10046 trace name context forever, level 12‘;

Session altered.

6. 执行测试sql(即将被跟踪的sql)
SQL> variable a number; #含有绷定变量的sql
SQL> exec :a:=2;
PL/SQL procedure successfully completed.

SQL> select count(*) from dba_objects where object_id=:a;

COUNT(*)
----------

7. 关闭10046事件
SQL> alter session set events ‘10046 trace name context off‘;

Session altered.

8.1 查看原始10046后的trace文件 注意:10046事件的trace文件内容是sql按时间顺序执行的结果

[[email protected] ~]$ vi /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2823.trc

Trace file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2823.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name: 11g
Release: 2.6.32-573.el6.x86_64
Version: #1 SMP Thu Jul 23 15:44:03 UTC 2015
Machine: x86_64
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 32
Unix process pid: 2823, image: [email protected] (TNS V1-V3)

*** 2014-11-19 04:42:30.941
*** SESSION ID:(45.14) 2014-11-19 04:42:30.941
*** CLIENT ID:() 2014-11-19 04:42:30.941
*** SERVICE NAME:(SYS$USERS) 2014-11-19 04:42:30.941
*** MODULE NAME:(SQL*Plus) 2014-11-19 04:42:30.941
*** ACTION NAME:() 2014-11-19 04:42:30.941

WAIT #2: nam=‘SQL*Net message to client‘ ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1416390150940558

*** 2014-11-19 04:44:47.004
WAIT #2: nam=‘SQL*Net message from client‘ ela= 136063164 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1416390287004294
CLOSE #2:c=0,e=3,dep=0,type=3,tim=1416390287004441
=====================
PARSING IN CURSOR #5 len=19 dep=0 uid=90 oct=47 lid=90 tim=1416390287005001 hv=3805855218 ad=‘87972f88‘ sqlid=‘1w9223jdjggk‘
BEGIN :a:=2; END;
END OF STMT
PARSE #5:c=0,e=467,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1416390287005001
BINDS #5:
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fd108695a28 bln=22 avl=00 flg=05
WAIT #5: nam=‘SQL*Net message to client‘ ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1416390287006240
EXEC #5:c=1999,e=1191,p=0,cr=0,cu=0,mis=1,r=1,dep=0,og=1,plh=0,tim=1416390287006261

*** 2014-11-19 04:56:00.212
WAIT #5: nam=‘SQL*Net message from client‘ ela= 673206425 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1416390960212735
CLOSE #5:c=0,e=49,dep=0,type=0,tim=1416390960212948
=====================
PARSING IN CURSOR #1 len=51 dep=0 uid=90 oct=3 lid=90 tim=1416390960213839 hv=3085049059 ad=‘87973410‘ sqlid=‘214vxnyvy4773‘
select count(*) from dba_objects where object_id=:a
END OF STMT
PARSE #1:c=1000,e=844,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1416390960213838
=====================
PARSING IN CURSOR #6 len=37 dep=1 uid=0 oct=3 lid=0 tim=1416390960214450 hv=1398610540 ad=‘9a8c2c00‘ sqlid=‘grwydz59pu6mc‘
select text from view$ where rowid=:1
END OF STMT
PARSE #6:c=1000,e=408,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1416390960214449
=====================
PARSING IN CURSOR #2 len=210 dep=2 uid=0 oct=3 lid=0 tim=1416390960215089 hv=864012087 ad=‘8a7b0300‘ sqlid=‘96g93hntrzjtr‘
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and intcol#=:2
END OF STMT
PARSE #2:c=0,e=292,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=0,tim=1416390960215089
BINDS #2:
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fd108751d48 bln=22 avl=02 flg=05
value=69
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fd108751d18 bln=24 avl=03 flg=05
value=1001
EXEC #2:c=1000,e=9315,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=2239883476,tim=1416390960224458
FETCH #2:c=0,e=28,p=0,cr=2,cu=0,mis=0,r=0,dep=2,og=3,plh=2239883476,tim=1416390960224573
STAT #2 id=1 cnt=0 pid=0 pos=1 obj=424 op=‘TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=0 pw=0 time=0 us)‘
STAT #2 id=2 cnt=0 pid=1 pos=1 obj=426 op=‘INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=0 us)‘
CLOSE #2:c=0,e=2,dep=2,type=3,tim=1416390960224765
=====================
PARSING IN CURSOR #5 len=210 dep=2 uid=0 oct=3 lid=0 tim=1416390960224900 hv=864012087 ad=‘8a7b0300‘ sqlid=‘96g93hntrzjtr‘
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and intcol#=:2
END OF STMT
BINDS #5:
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fd108751d48 bln=22 avl=02 flg=05
value=69
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fd108751d18 bln=24 avl=02 flg=05
value=8
EXEC #5:c=0,e=132,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=3,plh=2239883476,tim=1416390960225016
FETCH #5:c=0,e=12,p=0,cr=2,cu=0,mis=0,r=0,dep=2,og=3,plh=2239883476,tim=1416390960225045
CLOSE #5:c=0,e=1,dep=2,type=3,tim=1416390960225068
BINDS #6:
Bind#0
oacdty=11 mxl=16(16) mxlc=00 mal=00 scl=00 pre=00
oacflg=18 fl2=0001 frm=00 csi=00 siz=16 off=0
kxsbbbfp=7fd1086aa078 bln=16 avl=16 flg=05

。。。。。 省略大量输出

"~/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2823.trc" 148L, 8943C

8.2 使用tkprof工具查看10046时间的trace文件
[[email protected] ~]$ tkprof /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2823.trc andy.txt sys=no

TKPROF: Release 11.2.0.1.0 - Development on Wed Nov 19 05:00:35 2014

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

[[email protected] ~]$ vi andy.txt

from
dba_objects where object_id=:a

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 2 0.00 0.00 0 5 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.01 0.00 0 5 0 1

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 90

Rows Row Source Operation # 执行计划
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=5 pr=0 pw=0 time=0 us)
1 VIEW DBA_OBJECTS (cr=5 pr=0 pw=0 time=0 us cost=5 size=26 card=2)
1 UNION-ALL (cr=5 pr=0 pw=0 time=0 us)
1 FILTER (cr=5 pr=0 pw=0 time=0 us)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=0 us cost=5 size=71 card=1)
1 NESTED LOOPS (cr=4 pr=0 pw=0 time=0 us cost=4 size=67 card=1)
1 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=3 pr=0 pw=0 time=0 us cost=3 size=45 card=1)
1 INDEX RANGE SCAN I_OBJ1 (cr=2 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 36)
1 INDEX RANGE SCAN I_USER2 (cr=1 pr=0 pw=0 time=0 us cost=1 size=22 card=1)(object id 47)
1 INDEX RANGE SCAN I_USER2 (cr=1 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 TABLE ACCESS BY INDEX ROWID IND$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)
0 INDEX UNIQUE SCAN I_IND1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 41)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
0 INDEX FULL SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJ4 (cr=0 pr=0 pw=0 time=0 us cost=1 size=9 card=1)(object id 39)

————————————————————————————————————————————————————

二:跟踪指定会话 (具体步骤参上面部分,这里简写)

使用10046 事件跟踪启动trace
SQL> exec dbms_monitor.session_trace_enable(45,14,waits=>true,binds=>true)

PL/SQL procedure successfully completed.

关闭trace
SQL> exec dbms_monitor.session_trace_disable(45,14);

PL/SQL procedure successfully completed.

OK,结束。 转载请标明出处。

时间: 2024-08-25 05:17:37

10046事件跟踪会话sql的相关文章

SQL Tuning 基础概述03 - 使用sql_trace和10046事件跟踪执行计划

1.使用sql_trace跟踪执行计划 1.1 当前session跟踪: alter session set sql_trace = true; //开始sql_trace alter session set tracefile_identifier = jytrace; //设定trace文件的标识符 alter session set sql_trace = false; //结束sql_trace 1.2 其他session跟踪:(根据其他session的sid, serial#定位,最常

Oracle SQL Trace 和 10046 事件

一. 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> alte

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪监控死锁

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪监控死锁 我们通过SQL Server 2012图形界面来部署一个扩展事件跟踪会话.然后可以生成SQL脚本,在2008或2008 R2版本下运行类似的跟踪. 步骤1: 通过"Object Explorer"连接到实例,展开"Management"."Extended Events"."Sessions". 步骤2: 右键点击"Sess

获得执行计划方法四-使用10046事件

我们也可以通过设置10046事件来进行SQL跟踪,并且可以设置不同的跟踪级别,比使用SQL_TRACE获得更多的信息. 10046事件不但可以跟踪用户会话(trace文件位于USER_DUMP_DEST ),也可以跟踪background进程(trace文件位于BACKGROUND_DUMP_DEST ).trace文件的大小决定于4个因素:跟踪级别,跟踪时长,会话的活动级别和MAX_DUMP_FILE_SIZE参数. 启用跟踪事件10046 1.在全局设置 修改初始化参数 EVENT = "1

10046事件和tkprof命令

使用10046事件是在oralce数据库中查看目标sql的执行计划的另外一种方法.这种方法与使用explain plan命令,dbms_xplan包和autotrace开关的不同之处在于,所得到的执行计划的中明确显示了目标sql实际执行计划中每一个执行步骤所消耗的逻辑读,物理读和花费的时间.这种细粒度的明细显示在我们诊断复杂sql的性能问题时尤为有用,而且这也是其他三种方法所不能提供的(实际上,用gather_plan_statistisc hint配合dbms_xplan包一起使用也可也达到类

SQL Server扩展事件(Extended Events)-- 使用system_health默认跟踪会话监控死锁

SQL Server扩展事件(Extended Events)-- 使用system_health默认跟踪会话监控死锁 自SQL Server 2008以后,提供了扩展事件(Extended Events)来跟踪系统分析定位问题.默认的system_health会话一直在运行,可以帮助你更快的定位问题. 运行如下脚本可以看到system_health扩展事件会话: SELECT * FROM sys.dm_xe_sessions 即便是你没有启动任何扩展事件会话,这个查询也会返回一行system

SQL Server扩展事件-- 使用system_health默认跟踪会话监控死锁

SQL Server扩展事件(Extended Events)-- 使用system_health默认跟踪会话监控死锁 转自:http://blog.51cto.com/ultrasql/1600372 自SQL Server 2008以后,提供了扩展事件(Extended Events)来跟踪系统分析定位问题.默认的system_health会话一直在运行,可以帮助你更快的定位问题. 运行如下脚本可以看到system_health扩展事件会话: SELECT * FROM sys.dm_xe_

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪查询语句

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪查询语句 创建扩展事件会话 展开"Object Explorer"."Management"."Extended Events"."Sessions"目录,你会发现一到两个预设的会话.默认,在SQL Server 2012包含system_health会话,而根据不同的SQL Server2012的版本,可能有AlwaysOn_health会话

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪监控死锁脚本实现

SQL Server扩展事件(Extended Events)-- 使用扩展事件跟踪监控死锁脚本实现 -- Create a new event session (it is better to create a new session and not modify the system's built-in session "system_health"): CREATE EVENT SESSION [Deadlock_Monitor] ON SERVER ADD EVENT sql