SQL执行计划之sql_trace

一，sql_trace的做用：用以描述SQL的执行过程的trace输出。

     - SQL是如何操做数据的

     - SQL执行过程当中产生了哪些等待事件

     - SQL执行中消耗了多少资源

     - SQL的实际执行计划

     - SQL产生的递归语句

 

二，set autotrace 与 sql_trace的区别

     set autotrace用于输出优化器产生的执行计划，执行计划展现的资源消耗状况是CBO的估算值，并不必定是SQL实际执行时资源消耗状况。好比，向表t中插入10万条数据，执行查询的时候发现只返回少许数据，这可能就是表t尚未被Oracle重分析，它并不知道表的数据已更新。

     sql_trace是SQL实际的执行状况。

 

三，什么时候使用set autotrace 与 sql_trace

     当须要分析执行计划及CBO行为时，使用set autotrace；当要看一条SQL的真实运行效果时，使用sql_trace。

 

四，sql_trace的使用

     （1）收集本回话的SQL执行过程

     SQL>alter session set sql_trace=true

      SQL>alter session set statistics_level = all;          

     SQL>alter session set timed_statistics = true;          
     SQL>alter session set max_dump_file_size = unlimited;
     SQL>alter session set tracefile_identifier = liangjian

     SQL>sql.....

     SQL>alter session set sql_trace=false

     SQL>exit                         

 

     （2）收集其它会话的SQL执行过程

     SQL1>select sid, serial# from v$session;                                                            

     SQL2>execute  dbms_system.set_sql_trace_in_session(sid, serial#, true);           

     SQL2>sql....

     SQL2>execute  dbms_system.set_sql_trace_in_session(sid, serial#, false); 

 

五，trace文件内容

     生成的trace文件的目录由参数文件指定，能够经过v$diag_info视图来查看，name=Default Trace File的值就是trace文件的默认路径。下面是一个实际生成的trace文件：

　　

      trace文件内容：

  

     trace文件中记录的是Oracle按照时间前后顺序来输出的，它是Oracle执行SQL最底层的过程。上面第二个红色方框中体现的就是咱们所发出SQL执行的过程，其意思是：首先打开一个标号为4的游标，关联这条SQL语句，而后解析这条SQL语句（PARSE #4），其中mis=1表示共享区中没有可共享已解析SQL，故它执行的是一次硬解析，而后执行SQL语句，再而后获取数据，最后关闭游标。有时候游标标号相同的输出并不在一块儿，由于trace文件是按照时间的前后顺序输出的，这也最能反映Oracle内部的执行顺序。

 

     trace文件中有不少键值对信息，初次看trace文件也必定是看不懂的，下面介绍一下各个键所表明的含义：

     

六，tkprof格式化工具

     trace文件并不直观，为了让读者一目了然，Oracle提供了格式化trace文件的工具：tkprof

（1）tkprof命令

     Usage: tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ]

     参数说明

      tracefile：你要分析的trace文件的绝对路径

      outputfile：格式化后的文件绝对路径

      explain=user/password@connectstring，对每条SQL 语句肯定其执行规划，并将执行规划写到输出文件中。若是不是有explain，在trace文件中咱们看到的是SQL实际的执行路径，不会有sql的执行计划（能够对比实际执行规划和执行计划的差异）

     table=schema.tablename，在输出到输出文件前，用于存放临时表的用户名和表名。

     PRINT:只列出输出文件的最初N个SQL语句。默认为全部的SQL语句。

      AGGREGATE:若是= NO，则不对多个相同的SQL进行汇总。若是为yes则对trace文件中的相同sql进行合并。

     INSERT:SQL 语句的一种，用于将跟踪文件的统计信息存储到数据库中。在TKPROF建立脚本后，在将结果输入到数据库中。

      SYS:若是设置为yes，则全部sys用户的操做(也包含用户sql语句引起的递归sql)，这样能够减小分析出来的文件的复杂度，便于查看。

     sort:对trace文件的sql语句根据须要排序，其中比较有用的一个排序选项是fchela，即按照elapsed time fetching来对分析的结果排序（记住要设置初始化参数timed_statistics=true），生成的文件将把最消耗时间的sql放在最前面显示。

 

     执行计划分为两部分，第一部分称为行源操做(Row Source Operation )，是游标关闭且开启跟踪状况下写到跟踪文件中的执行计划。这意味着若是应用程序不关闭游标而重用它们的话，不会有新的针对重用游标的执行计划写入到跟踪文件中。第二部分，叫作执行计划 (Execution Plan)，是由指定了explain参数的TKPROF生成的。既然这是随后生成的，因此和第一部分不必定彻底匹配。万一看到二者不一致，前者是正确的。两个执行计划都经过Rows列提供执行计划中每一个操做返回的行数（不是处理的--要注意）。 对于每一个行源操做来讲，可能还会提供以下的运行时统计： 

     cr是一致性模式下逻辑读出的数据块数。

     pr是从磁盘物理读出的数据块数。

     pw是物理写入磁盘的数据块数。

     time是以微秒表示的总的消逝时间。要注意根据统计获得的值不老是精确的。实际上，为了减小开销，可能用了采样。

     cost是操做的评估开销。这个值只有在Oracle 11g才提供。

     size是操做返回的预估数据量(字节数)。这个值只有在Oracle 11g才提供。 

     card是操做返回的预估行数。这个值只有在Oracle 11g才提供。 

 

     输出文件的结尾给出了全部关于跟踪文件的信息。首先能够看到跟踪文件名称、版本号、用于这个分析所使用的参数sort的值。而后，给出了全部会话数量与SQL语句数量。 

     Optimizer mode: ALL_ROWS表示优化器采用的是all_rows的模式

     Parsing user id: 55 表示用户id为55 

 

 

（2）格式化后输出文件的解释

     首先解释输出文件中列的含义：

     CALL：每次SQL语句的处理都分红三个部分

     Parse：这步将SQL语句转换成执行计划，包括检查是否有正确的受权和所须要用到的表、列以及其余引用到的对象是否存在。

     Execute：这步是真正的由Oracle来执行语句。对于insert、update、delete操做，这步会修改数据，对于select操做，这步就只是肯定选择的记录。

     Fetch：返回查询语句中所得到的记录，这步只有select语句会被执行。

     COUNT:这个语句被parse、execute、fetch的次数。

     CPU：这个语句对于全部的parse、execute、fetch所消耗的cpu的时间，以秒为单位。

     ELAPSED：这个语句全部消耗在parse、execute、fetch的总的时间。

     DISK：从磁盘上的数据文件中物理读取的块的数量。

     QUERY：在一致性读模式下，全部parse、execute、fetch所得到的buffer的数量。一致性模式的buffer是用于给一个长时间运行的事务提供一个一致性读的快照，缓存实际上在头部存储了状态。

     CURRENT：在current模式下所得到的buffer的数量。通常在current模式下执行insert、update、delete操做都会获取buffer。在current模式下若是在高速缓存区发现有新的缓存足够给当前的事务使用，则这些buffer都会被读入了缓存区中。

     ROWS: 全部SQL语句返回的记录数目，可是不包括子查询中返回的记录数目。对于select语句，返回记录是在fetch这步，对于insert、update、delete操做，返回记录则是在execute这步。

 

（3）trace文件中的性能分析 

     一、若是分析数与执行数之比为1，说明每次执行这个查询都要进行sql解析。若是分析数与执行数之比接近0，则意味着查询执行了不少次软解析，下降了系统的可伸缩性。

     二、若是trace文件中显示对全部或者几乎全部的sql都执行一次，那有多是由于没有正确使用绑定变量。

     三、若是一个(Fetch Count)/所得到行数的比值接近1，且行数大于1，则应用程序不执行大批量取数操做，每种语言/API都有能力完成这个功能，即一次取多行。若是没有利用这个功能进行批量去，将有可能花费多得多的时间在客户端与服务器端之间来回往返。这个过多的来回转换出了产生很拥挤的网络情况以外，也会比一次调用得到不少行要慢得多，如何指示应用程序进行批量获取将随语言/API而定。

     四、若是CPU时间与elasped时间有巨大差别，意味着有可能花了大量时间在等待某些事情上。若是花了一个CPU时间来执行，但它却总共花了10秒的时间，这就意味着90%的运行时间在等待一个资源。例如被一个会话等待，或者大量查询时的物理IO等待等

     五、较长的CPU或通过时间每每是最消耗资源的sql，须要咱们关注

     六、能够经过磁盘IO所占逻辑IO的比例，disk/query+current来判断磁盘IO的状况，太大的话有多是db_buffer_size太小，固然这也跟SQL的具体特性有关

     七、query+current/rows 平均每行所需的block数，太大的话（超过20）SQL语句效率过低，数据过于分散，能够考虑重组对象

 

 转载请注明出处： http://www.cnblogs.com/pengineer/p/4610390.html