SQL_TRACE与tkprof分析

简介:

一. 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 sql命令启动SQL_TRACE

SQL> alter session set sql_trace=true;
Session altered.

2 通过设置trace 文件标识

SQL> alter session set tracefile_identifier='andy';
Session altered.

设置标识的目的就是方便我们查找生成的trace文件。我们只需要在trace目录查找文件名里带有标识的文件即可。 在Oracle 10g中,SQL_TRACE生成的trace文件默认路劲是$ORACLE_BASE/admin/SID/udump.

到了11g,trace 默认路径在:$ORACLE_BASE/diag/rdbms/orcl/orcl/trace目录下.

3. 直接用如下SQL直接查出,当前的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_24020_andy.trc

4. 进行相关事务操作
SQL> select * from t;

5. 关闭SQL_TRACE
SQL> alter session set sql_trace=false;

会话已更改。

注意,这里是显示的关闭SQL_TRACE,在session级别,也可以直接退出SQLPLUS来终止SQL_TRACE。

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

6. 查看trace 文件(原始查看方式,即不使用tkprof工具查看)

如果想确切的知道SQL 语句的每一步执行是如果操作的,就需要分析原始的trace文件。 这个trace 虽然没有tkprof工具处理之后易读,但是却能够清楚的知道SQL在那个点做了什么,以及SQL是如何工作的,这对与理解SQL语句的执行过程非常有用。


直接打开 /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.trc文件:

T[oracle@11g ~]$ vi /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.trc

Trace file /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.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
Oracle process number: 19
Unix process pid: 24020, image: oracle@11g (TNS V1-V3)

。。。。。省略输出

*** 2014-11-17 08:06:08.981
CLOSE #1:c=0,e=14,dep=0,type=1,tim=1416229568981377
=====================
PARSING IN CURSOR #1 len=23 dep=0 uid=0 oct=3 lid=0 tim=1416229568981763 hv=665675061 ad='87d2dfb0' sqlid='ckyh1gcmuut9p'
select * from dba_users
END OF STMT
PARSE #1:c=0,e=291,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3422547789,tim=1416229568981762
EXEC #1:c=0,e=135,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3422547789,tim=1416229568981961
FETCH #1:c=4000,e=3231,p=0,cr=52,cu=0,mis=0,r=1,dep=0,og=1,plh=3422547789,tim=1416229568985261
FETCH #1:c=0,e=67,p=0,cr=1,cu=0,mis=0,r=15,dep=0,og=1,plh=3422547789,tim=1416229568985934
FETCH #1:c=0,e=64,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3422547789,tim=1416229569004724
FETCH #1:c=0,e=83,p=0,cr=1,cu=0,mis=0,r=4,dep=0,og=1,plh=3422547789,tim=1416229569022491
STAT #1 id=1 cnt=35 pid=0 pos=1 obj=0 op='HASH JOIN (cr=54 pr=0 pw=0 time=0 us cost=26 size=2664 card=12)'
STAT #1 id=2 cnt=35 pid=1 pos=1 obj=0 op='HASH JOIN (cr=49 pr=0 pw=0 time=0 us cost=24 size=2436 card=12)'
STAT #1 id=3 cnt=35 pid=2 pos=1 obj=0 op='HASH JOIN (cr=34 pr=0 pw=0 time=34 us cost=18 size=2316 card=12)'
STAT #1 id=4 cnt=35 pid=3 pos=1 obj=0 op='HASH JOIN OUTER (cr=19 pr=0 pw=0 time=68 us cost=13 size=2196 card=12)'
STAT #1 id=5 cnt=35 pid=4 pos=1 obj=0 op='HASH JOIN (cr=16 pr=0 pw=0 time=0 us cost=10 size=1740 card=12)'
STAT #1 id=6 cnt=35 pid=5 pos=1 obj=0 op='HASH JOIN (cr=13 pr=0 pw=0 time=136 us cost=8 size=1620 card=12)'
STAT #1 id=7 cnt=2 pid=6 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=6 pr=0 pw=0 time=1 us cost=4 size=26 card=1)'
STAT #1 id=8 cnt=1 pid=7 pos=1 obj=280 op='TABLE ACCESS FULL PROFILE$ (cr=3 pr=0 pw=0 time=0 us cost=2 size=13 card=1)'
STAT #1 id=9 cnt=2 pid=7 pos=2 obj=0 op='BUFFER SORT (cr=3 pr=0 pw=0 time=1 us cost=2 size=13 card=1)'
STAT #1 id=10 cnt=2 pid=9 pos=1 obj=280 op='TABLE ACCESS FULL PROFILE$ (cr=3 pr=0 pw=0 time=1 us cost=2 size=13 card=1)'
STAT #1 id=11 cnt=35 pid=6 pos=2 obj=22 op='TABLE ACCESS FULL USER$ (cr=7 pr=0 pw=0 time=102 us cost=3 size=3597 card=33)'
STAT #1 id=12 cnt=2 pid=5 pos=2 obj=281 op='TABLE ACCESS FULL PROFNAME$ (cr=3 pr=0 pw=0 time=1 us cost=2 size=10 card=1)'
STAT #1 id=13 cnt=2 pid=4 pos=2 obj=297 op='TABLE ACCESS FULL RESOURCE_GROUP_MAPPING$ (cr=3 pr=0 pw=0 time=0 us cost=2 size=38 card=1)'
STAT #1 id=14 cnt=8 pid=3 pos=2 obj=16 op='TABLE ACCESS FULL TS$ (cr=15 pr=0 pw=0 time=105 us cost=5 size=80 card=8)'
STAT #1 id=15 cnt=8 pid=2 pos=2 obj=16 op='TABLE ACCESS FULL TS$ (cr=15 pr=0 pw=0 time=14 us cost=5 size=80 card=8)'
STAT #1 id=16 cnt=9 pid=1 pos=2 obj=292 op='TABLE ACCESS FULL USER_ASTATUS_MAP (cr=5 pr=0 pw=0 time=0 us cost=2 size=171 card=9)'

这个文件的可读性要差很多。 对这里面的一些参数做些说明:


PARSING IN CURSOR 部分: PARSE,EXEC,FETCH 部分 STATS 部分:

Len: 被解析SQL的长度 C: 消耗的CPU time Id: 执行计划的行源号 
Dep: 产生递归SQL的深度 E:elapsed time 操作的用时 Cnt:当前行源返回的行数

Uid:user id P: physical reads 物理读的次数 Pid:当前行源号的父号

Otc: Oracle command type 命令的类型 Cr: consistent reads 一致性方式读取的数据块 Pos:执行计划中的位置

Lid: 私有用户id Cu:current 方式读取的数据块 Obj:当前操作的对象id(如果当前行原始一个对象的话)

Tim:时间戳 Mis:cursor misss in cache 硬分析次数 Op:当前行源的数据访问操作

Hv: hash value R: -rows 处理的行数

Ad:SQL address Dep: depth 递归SQL的深度

Og: optimizer goal 优化器模式

Tim:timestamp时间戳


二. TKPROF 工具


SQL_TRACE 生成最原始的trace文件的可读性比较差,所以通常我们使用tkprof 工具来处理trace文件。 Tkprof 工具是Oracle 自带的一个工具,用于处理原始的trace文件,它的作用主要是合并汇总trace文件中的一些项,规范化文件的格式,使文件更具有可读性。

注意:tkprof 工具只能用在处理SQL_TRACE和10046事件产生的trace,其他事件如10053不能处理。

Tkprof 是系统级别的,直接在系统下执行即可。先看一下tkprof的帮助文档:

[oracle@11g ~]$ 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 用tkprof工具查看中生成的trace文件


[oracle@11g ~]$ tkprof /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.trc andy.txt sys=no


[oracle@11g ~]$ vi andy.txt

TKPROF: Release 11.2.0.1.0 - Development on Mon Nov 17 08:25:36 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.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的版本信息,以及报告中一些列的含义

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS #非递归SQL语句

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 6 0.00 0.03 0 54 0 36
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 0.00 0.03 0 54 0 36

Misses in library cache during parse: 0

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 0 0.00 0.00 0 0 0 0

Misses in library cache during parse: 0 #shared pool 命中,说明做了0次硬解析。

2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.

Misses in library cache during parse: 0

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 0 0.00 0.00 0 0 0 0

Misses in library cache during parse: 0

2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
********************************************************************************
Trace file: /home/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_24020_andy.trc
Trace file compatibility: 11.1.0.7
Sort options: default

1 session in tracefile.
2 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
2 unique SQL statements in trace file.
71 lines in trace file.
1719 elapsed seconds in trace file.

ok,结束。

 


本文转自 张冲andy 博客园博客,原文链接: http://www.cnblogs.com/andy6/p/6194452.html ,如需转载请自行联系原作者


相关文章
|
7月前
|
SQL 索引
19. 一个SQL语句执行很慢, 如何分析
该内容介绍了如何分析执行慢的SQL语句。首先启用慢查询日志或使用命令获取慢查询的SQL。然后利用`EXPLAIN`命令分析,关注其中的`select_type`, `type`, 和 `extra`字段。`select_type`涉及子查询和联合查询的类型,`type`表示查询优化器使用的访问类型,性能从上到下递减,`extra`字段提供额外信息,如是否使用索引等。
60 0
|
2月前
|
SQL 存储 数据可视化
手机短信SQL分析技巧与方法
在手机短信应用中,SQL分析扮演着至关重要的角色
|
7月前
|
SQL 数据可视化 算法
SQL Server聚类数据挖掘信用卡客户可视化分析
SQL Server聚类数据挖掘信用卡客户可视化分析
|
4月前
|
前端开发 Java JSON
Struts 2携手AngularJS与React:探索企业级后端与现代前端框架的完美融合之道
【8月更文挑战第31天】随着Web应用复杂性的提升,前端技术日新月异。AngularJS和React作为主流前端框架,凭借强大的数据绑定和组件化能力,显著提升了开发动态及交互式Web应用的效率。同时,Struts 2 以其出色的性能和丰富的功能,成为众多Java开发者构建企业级应用的首选后端框架。本文探讨了如何将 Struts 2 与 AngularJS 和 React 整合,以充分发挥前后端各自优势,构建更强大、灵活的 Web 应用。
65 0
|
4月前
|
SQL 数据采集 数据挖掘
为什么要使用 SQL 函数?详尽分析
【8月更文挑战第31天】
65 0
|
4月前
|
SQL 数据采集 算法
【电商数据分析利器】SQL实战项目大揭秘:手把手教你构建用户行为分析系统,从数据建模到精准营销的全方位指南!
【8月更文挑战第31天】随着电商行业的快速发展,用户行为分析的重要性日益凸显。本实战项目将指导你使用 SQL 构建电商平台用户行为分析系统,涵盖数据建模、采集、处理与分析等环节。文章详细介绍了数据库设计、测试数据插入及多种行为分析方法,如购买频次统计、商品销售排名、用户活跃时间段分析和留存率计算,帮助电商企业深入了解用户行为并优化业务策略。通过这些步骤,你将掌握利用 SQL 进行大数据分析的关键技术。
257 0
|
4月前
|
SQL 数据挖掘 BI
【超实用技巧】解锁SQL聚合函数的奥秘:从基础COUNT到高级多表分析,带你轻松玩转数据统计与挖掘的全过程!
【8月更文挑战第31天】SQL聚合函数是进行数据统计分析的强大工具,可轻松计算平均值、求和及查找极值等。本文通过具体示例,展示如何利用这些函数对`sales`表进行统计分析,包括使用`COUNT()`、`SUM()`、`AVG()`、`MIN()`、`MAX()`等函数,并结合`GROUP BY`和`HAVING`子句实现更复杂的数据挖掘需求。通过这些实践,你将学会如何高效地应用SQL聚合函数解决实际问题。
64 0
|
4月前
|
网络协议 NoSQL 网络安全
【Azure 应用服务】由Web App“无法连接数据库”而逐步分析到解析内网地址的办法(SQL和Redis开启private endpoint,只能通过内网访问,无法从公网访问的情况下)
【Azure 应用服务】由Web App“无法连接数据库”而逐步分析到解析内网地址的办法(SQL和Redis开启private endpoint,只能通过内网访问,无法从公网访问的情况下)
|
5月前
|
SQL 存储 大数据
SQL中DISTINCT关键字的使用与性能影响分析
SQL中DISTINCT关键字的使用与性能影响分析
|
7月前
|
SQL HIVE UED
【Hive SQL 每日一题】分析电商平台的用户行为和订单数据
作为一名数据分析师,你需要分析电商平台的用户行为和订单数据。你有三张表:`users`(用户信息),`orders`(订单信息)和`order_items`(订单商品信息)。任务包括计算用户总订单金额和数量,按月统计订单,找出最常购买的商品,找到平均每月最高订单金额和数量的用户,以及分析高消费用户群体的年龄和性别分布。通过SQL查询,你可以实现这些分析,例如使用`GROUP BY`、`JOIN`和窗口函数来排序和排名。
409 2