五、阅读TKPROF格式化的文件
    经过TKPROF格式化后的文件内容，就比较容易阅读了，我截取了格式化后的文件中的一段：

********************************************************************************
第一部分为sql语句文本。

insert into audit_result_temp Select nvl(count(distinct file_id), :"SYS_B_0")
from (Select file_id from log_collect where standard_flag=:"SYS_B_1" and
Billing_cycle_id=:"SYS_B_2" Minus Select file_id from log_import where
billing_cycle_id=:"SYS_B_3")

第二部分主要反映执行效率，主要关注cpu、disk、query、rows几项

Cpu反映SQL语句的 CPU解析和执行时间

Disk反映磁盘读取情况，可以理解成物理读次数，越小越好。

Query主要是反映查询的中间结果有多少行次，执行了多少次查询。

Rows最终结果返回了多少行

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ---------- 
Parse 10 0.01 0.00 0 0 0 0
Execute 11 48.26 74.81 0 1477212 398 11
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ---------- 
total 21 48.27 74.81 0 1477212 398 11

第三部分，是此语句的执行计划，主要关注是否进行了全表扫描。

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 22 (recursive depth: 1)

Rows Row Source Operation
------- --------------------------------------------------- 
2 SORT GROUP BY
0 VIEW
0 MINUS
0 SORT UNIQUE
0 TABLE ACCESS FULL LOG_COLLECT
0 SORT UNIQUE
0 TABLE ACCESS FULL LOG_IMPORT 

********************************************************************************

几种典型情况：

1、 如果query很大，rows很小，就明显有问题，表示运行了很多的中间查询，而最终只返回了很少的行。

2、 Disk读很大。Disk如果很大，要检查下面的执行计划，是否用全表扫描，使用了不正确的索引等。从磁盘读取过多，速度肯定很慢。

3、 CPU时间过大，可能是SQL语句很复杂，或没有使用绑定变量的原因

通过以上过程，就可以对所有的耗CPU时间比较大的进程的SQL进行分析了。