如何通过跟踪一个客户端程序发出的sql的方法来优化SQL

如何通过跟踪一个客户端程序发出的sql的方法来优化SQL
简要说来，跟踪一个客户程序发出的SQL主要分成下面几步：
1) 识别要跟踪的客户端程序到数据库的连接(后面都用session代替)，主要找出能唯一识别一个session的sid与serial#.
2) 设定相应的参数，如打开时间开关(可以知道一个sql执行了多长时间)，存放跟踪数据的文件的位置、最大值。
3) 启动跟踪功能
4) 让系统运行一段时间，以便可以收集到跟踪数据
5) 关闭跟踪功能
6) 格式化跟踪数据，得到我们易于理解的跟踪结果。
现在就每一步，给出详细的说明：
1) 识别要跟踪的客户端程序到数据库的数据库连接
查询session信息(在sql*plus中运行)：
set linesize 190
col machine format a30 wrap
col program for a40
col username format a15 wrap
set pagesize 500
select s.sid sid, s.SERIAL# "serial#", s.username, s.machine, s.program,
p.spid ServPID, s.server,s.login_time
from v$session s, v$process p
where p.addr = s.paddr ;
如得到的一个查询结果如下：
SID serial# USERNAME MACHINE PROGRAM SERVPID SERVER
---- ------- -------- ------------------ ------------- --------- ---------
8 3 SCOTT WORKGROUP\SUNNYXU SQLPLUS.EXE 388 DEDICATED
LOGON_TIME
------------------
2005.06.28 18:50:11
上面的结果中比较有用的列为：
sid, serial# : 这两个值联合起来唯一标识一个session
username : 程序连接数据库的用户名
machine : 连接数据库的程序所在的机器的机器名，可以hostname得到
program : 连接数据库的程序名，所有用java jdbc thin的程序的名字都一样，
servpid : 与程序对应的服务器端的服务器进程的进程号，在unix下比较有用
server : 程序连接数据库的模式：专用模式(dedicaed)、共享模式(shared)。 55
只有在专用模式下的数据库连接，对其进程跟踪才有效
logon_time : 程序连接数据库的登陆时间
根据machine, logon_time 可以方便的识别出一个数据库连接对应的session，从而得到该sesion的唯一标识sid, serial#, 为对该session进行跟踪做好准备
2) 设定相应的参数
参数说明：
timed_statistics : 收集跟踪信息时，是否将收集时间信息，如果收集，
则可以知道一个sql的各个执行阶段耗费的时间情况
user_dump_dest : 存放跟踪数据的文件的位置
max_dump_file_size : 放跟踪数据的文件的最大值，防止由于无意的疏忽，
使跟踪数据的文件占用整个硬盘，影响系统的正常运行
设置的方法：
SQL> exec sys.dbms_system.set_bool_param_in_session( -
sid => 8, -
serial# => 3, -
parnam => 'timed_statistics', -
bval => true);
SQL> alter system set user_dump_dest='c:\temp';
-- 注意这个语句会改变整个系统的跟踪文件存放的位置，所以我一般不改这个参数，而用系统的缺省值，要查看当前系统的该参数的值，可以用system用户登陆后：
SQL> show parameter user_dump_dest
SQL> exec sys.dbms_system.set_int_param_in_session( -
sid => 8, -
serial# => 3, -
parnam => 'max_dump_file_size', -
intval => 2147483647)

 

注意有时会报 错：提示信息如下

第 1 行出现错误:
ORA-06550: 第 1 行, 第 7 列:
PLS-00201: 必须声明标识符 'SYS.DBMS_SYSTEM'
ORA-06550: 第 1 行, 第 7 列:
PL/SQL: Statement ignored

原因是没有全权，解决办法   SQL> conn / as sysdba;

3) 启动跟踪功能
SQL> exec sys.dbms_system.set_sql_trace_in_session(8, 3, true);
注意，只有跟踪的session再次发出sql语句后，才会产生trc文件
4) 让系统运行一段时间，以便可以收集到跟踪数据
5) 关闭跟踪功能
SQL> exec sys.dbms_system.set_sql_trace_in_session(8,3,false);
6) 格式化跟踪数据，得到我们易于理解的跟踪结果。
对产生的trace文件进行格式化：
在命令提示符下，运行下面的命令 56
tkprof dsdb2_ora_18468.trc dsdb2_trace.out SYS=NO EXPLAIN=SCOTT/TIGER
其它使用tkprof的例子：
(a) tkprof tracefile.trc sort_1.prf explain=apps/your_apps_password print=10 sort='(prsqry,exeqry,fchqry,prscu,execu,fchcu)' (b) tkprof tracefile.trc sort_2.prf explain=apps/your_apps_password print=10 sort='(prsela,exeela,fchela)' (c) tkprof tracefile.trc sort_3.prf explain=apps/your_apps_password print=10 sort='(prscnt,execnt,fchcnt)' (d) tkprof tracefile.trc normal.prf explain=apps/your_apps_password
现对tkprof程序做进一步的说明：
在打开跟踪功能后，oracle将被跟踪session中正在执行的SQL的性能状态数据都收集到一个跟踪文件中。这个跟踪文件提供了许多有用的信息，例如一个sql的解析次数、执行次数、fetch次数、物理读次数、逻辑读次数、CPU使用时间等，利用这些信息可以诊断你的sql的问题，从而用来优化你的系统。不幸的是，生成的跟踪文件中的数据是我们难以理解的，所以要用TKPROF工具对其进行转换，转换成我们易于理解格式。tkprof是oracle提供的实用工具，类似于sql*plus，在安装完oracle客户端后就自动安装到系统中，直接在命令符下用就可以了。
当在打开跟踪功能时发生了recursive calls，则tkprof也会产生这些recursive calls的统计信息，并清楚的在格式化输出文件中标名它们为recursive calls。
注意：recursive calls的统计数据是包含在recursive calls上的，并不包含在引起该recursive calls语句的sql语句上面。所以计算一个sql语句耗费的资源时，也要考虑该sql语句引起recursive calls语句花费的资源。通过将sys参数设为no时，我们变可以在格式化的输出文件中屏蔽掉这些recursive calls信息。
如何得到tkprof的帮助信息：
运行tkprof时，不带任何参数，就可以得到该工具的帮助信息。
执行计划：
---------------
一个语句的执行计划是oracle执行这个sql语句的一系列指令。通过检验执行计划，你可以更好的知道oracle如何执行你的sql语句，这个信息可以帮助你决定是否你写的sql语句已经使用了索引。
如果在tkprof中指定了EXPLAIN参数，tkprof使用EXPLAIN PLAN命令来为每个被跟踪的sql语句产生执行计划。
使用说明：
TKPROF工具接受一个trace文件作为输入文件，利用提供给命令的多个参数对trace文件进行分析，然后将格式化好的结果放到一个输出文件中。
TKPROF的使用语法： 57
----------------
TKPROF command ::=
>>-- TKPROF traced_file formatted_file ---------------------------------------------->
| |
+- SORT = ---------------------------------+
| |
+-- OPTION --+
| |
| +---- , ----+ |
| V | |
|__( OPTION )__|
>----------------------------------------------------------------------------->
| | | | | |
+-- PRINT = integer --+ +-- INSERT = filname3 --+ +-- SYS = ---------+
| |
+- YES -+
| |
+- NO --+
>----------------------------------------------------------------------------->
| |
+---------------------------------------- EXPLAIN = user/password ------+
| |
+---- TABLE = schema.table ----+
>----------------------------------------------------------------------------><
| |
+---- RECORD = filname ----+
各个参数的含义：
' traced_file '
指定输入文件，即oracle产生的trace文件，该文件中可以只包含一个
session的跟踪信息，也可以包含系统中所有session的信息(此时需要在
系统级进行跟踪)
'formatted_file'
指定输出文件，即我们想得到的易于理解的格式化文件，我们利用该文件
对会话运行的sql进行分析。
'EXPLAIN'
利用哪个用户对trace文件中的sql进行分析，从而得到该sql语句的
执行计划，这也说明在trace file中并没有各个sql语句的执行计划，只是在运
行tkprof程序时才将trace file文件中的sql语句用explian参数指定的
用户连接到数据库，然后运用EXPLAIN PLAN命令生成sql的执行计划。 58
这个用户一般是你的程序中连接数据库的用户
'TABLE'
在对sql语句进行分析时，将产生的执行计划暂时存放到该表中。
一般不需要该参数，这样当表不存在时，tkprof会自动创建相应的表，
并在分析完之后，将创建的表自动删除。如果要指定自定义的表，该表的结构
必须与utlxplan.sql文件中指定的表的结构一样。
我一般不设置这个参数，让其采用默认的表名，并自动创建、删除
'SYS'
是否对sys用户运行的sql语句或被跟踪session产生的recursive SQL
也进行分析，并将分析结果放到输出文件中。缺省值为YES。
我一般设为NO，这样输出文件中只包含我发出的sql语句，
而不包含系统产生的sql。
SORT
按照指定的排序选项(条件)对格式化好的sql语句进行降序排列，然后存放
到输出文件中。可以将多个排序选项组合起来，如果没有指定排序选项，
则按照使用sql的先后顺序。
排序选项有：
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
PRINT
只列出指定数量的已排序的sql语句，排序的条件参见SORT参数。
如果忽略此参数，tkprof将跟踪文件中的所有的sql语句及其相关的 59
分析数据存放到输出文件中。
Print与sort参数组合在一起，可以实现:
找出某一阶段耗费cpu最多的前n个sql
找出某一阶段读硬盘最多的前n个sql等等。
INSERT
创建一个sql脚本文件，里面包含create table 与insert语句。
利用这个脚本文件创建一个表及插入数据后，可以得到跟踪文件中
所有sql语句(包含recursive SQL)的统计信息。如
,depth,user_id,
parse_cnt,parse_cpu,parse_elap,parse_disk,
parse_query,parse_current,parse_miss
,exe_count,exe_cpu,exe_elap,exe_disk,exe_query,
exe_current,exe_miss,exe_rows
,fetch_count,fetch_cpu,fetch_elap,fetch_disk,
fetch_query,fetch_current,fetch_rows,ticks
,sql_statement。
利用这些信息，也可以发现有问题的sql。即是格式化好的输出文件中
有关sql性能信息数据的数据库表的形式。
我一般不用该参数
RECORD
创建一个包含客户端程序发出的所有的sql语句的脚本文件。
注意，并不包含recursive SQL 。想知道它的用处吗？
对了可以窥探别人程序是如何访问数据库的，从而对了解程序的访问流程。
此时，最好不用sort参数，这样就可以按先后发出的顺序的到sql.
例子1：
将跟踪文件"dsdb2_ora_18468.trc"进行分析，并将其格式的结果放到"dsdb2_trace.out"文件中：
TKPROF dsdb2_ora_18468.trc dsdb2_trace.out SYS=NO EXPLAIN=SCOTT/TIGER
上面的例子中：
EXPLAIN参数让TKPROF程序连接到SCOTT用户，然后用EXPLAIN PLAN命令给跟踪文件中的sql语句产生执行计划。SYS参数的值为NO，这样TKPROF就会忽略该跟踪文件中的recursive SQL。
例子2：
TKPROF DLSUN12_JANE_FG_SVRMGR_007.TRC OUTPUTA.PRF
EXPLAIN=SCOTT/TIGER TABLE=SCOTT.TEMP_PLAN_TABLE_A
INSERT=STOREA.SQL SYS=NO SORT=(EXECPU,FCHCPU)
注意上面的所有命名应该都在一行中，否则需要有换行符。
上面的例子中： 60
TABLE参数使TKPROF使用scott用户下的TEMP_PLAN_TABLE_A表作为临时存放sql执行计划的表。
INSERT参数使TKPROF产生一个名为STOREA.SQL的脚本文件，存放所有被跟踪的sql语句的统计数据。
SORT参数使TKPROF先按照sql语句使用的cpu执行时间与该语句fetch操作使用的cpu时间进行排序，然后将其写到输出文件中。
解释tkprof程序产生的格式化文件：
tkprof的格式化输出文件主要包含两大部分：
header
body
summary
header：
主要包括一些描述信息，如TKPROF的版本、运行时间，各个统计项的描述。如：
TKPROF: Release 8.1.7.0.0 - Production on 星期四 6月 30 13:10:59 2005
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Trace file: D:\oracle\admin\xyj\udump\ORA01720.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
********************************************************************************
body：
是我们主要关心的地方，有我们感兴趣的信息。如sql语句、sql语句的统计信息、sql语句的执行计划等。如
select *
from
emp
call count cpu elapsed disk query current rows
------- ----- ----- ------- ----- ------ -------- -----
Parse 3 0.00 0.00 1 0 1 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 6 0.00 0.00 1 6 12 36 61
------- ----- ----- ------- ----- ------ -------- -----
total 12 0.00 0.00 2 6 13 36
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 19 (SCOTT)
Rows Row Source Operation
------- ---------------------------------------------------
12 TABLE ACCESS FULL EMP
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: CHOOSE
12 TABLE ACCESS (FULL) OF 'EMP'
DELETE FROM RM$HASH_ELMS
call count cpu elapsed disk query current rows
------- ------ ------ -------- ----- ------ -------- ----
Parse 2 0.00 0.00 0 0 0 0
Execute 29 12.04 12.61 6786 6853 108 19
Fetch 0 0.00 0.00 0 0 0 0
------- ------ ------ -------- ----- ------ -------- ----
total 31 12.04 12.61 6786 6853 108 19
Misses in library cache during parse: 0
Optimizer hint: CHOOSE
Parsing user id: 9 (DES12A) (recursive depth: 3)
Rows Execution Plan
------- ---------------------------------------------------
0 DELETE STATEMENT HINT: CHOOSE
16 TABLE ACCESS (FULL) OF 'RM$HASH_ELMS'
summary：
对所有的sql语句各个执行阶段的统计数据的汇总：
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS - - 标明是用户发出的sql语句的统计数据的汇总
call count cpu elapsed disk query current rows
------- ------ -------- -------- ----- ------ -------- -----
Parse 7 0.00 0.00 2 201 2 0
62
Execute 7 0.00 0.00 1 2 7 1
Fetch 10 0.00 0.00 2 67 16 52
------- ------ -------- -------- ----- ------ -------- -----
total 24 0.00 0.00 5 270 25 53
Misses in library cache during parse: 5
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS - - 标明是系统发出的sql语句的统计数据的汇总
call count cpu elapsed disk query current rows
------- ------ ------ -------- ----- ------ -------- ----
Parse 75 0.00 0.00 2 3 2 0
Execute 81 0.00 0.00 1 1 5 1
Fetch 153 0.00 0.00 21 355 0 110
------- ------ ------ -------- ----- ------ -------- ----
total 309 0.00 0.00 24 359 7 111
Misses in library cache during parse: 29
8 user SQL statements in session.
74 internal SQL statements in session.
82 SQL statements in session.
5 statements EXPLAINed in this session.
*********************************************************************
Trace file: D:\oracle\admin\xyj\udump\ORA01720.TRC
Trace file compatibility: 8.00.04
Sort options: default
1 session in tracefile.
8 user SQL statements in trace file.
74 internal SQL statements in trace file.
82 SQL statements in trace file.
34 unique SQL statements in trace file.
5 SQL statements EXPLAINed using schema:
SCOTT.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
825 lines in trace file.
现只对body中的每部分作出详细说明： 63
1) sql语句的统计信息
我们把select语句的执行过程分成3个阶段(分析