0 UPDATE EMP (cr=1 pr=0 pw=0 time=0 us)
1 INDEX UNIQUE SCAN EMP_PK (cr=1 pr=0 pw=0 time=0 us cost=0 size=26 card=1)(object id 73464)
Rows Execution Plan
------- ---------------------------------------------------
0 UPDATE STATEMENT MODE: ALL_ROWS
0 UPDATE OF 'EMP'
1 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'EMP_PK' (INDEX
(UNIQUE))
********************************************************************************
执行统计有如下的几列：
count：表示执行的数据库调用数量。
cpu：表示处理数据调用花去的CPU时间，以秒为单位。
elapsed：是处理数据库调用花费的总的时间，以秒为单位，如果这个值比CPU时间高，下一节关于执行统计中的等待事件会提供在等待的资源或同步点。
disk：表示物理读的数据块数量。要当心，这不是物理I/O操作的数量，物理I/O操作数在关于等待事件一节给出。如果这个值大于逻辑读的数量(disk > query +current)，这意味着数据块填充进了临时表空间。
query：是在一致性模式（consistent mode）下从高速缓存逻辑读取的块数量。通常，这类型的逻辑读用作查询。
current：代表在当前模式下从高速缓存逻辑读取的块数量。通常，这类逻辑读被INSERT、DELETE、MERGE以及UPDATE等语句所使用。
rows：代表处理的数据行数量。对于查询来说，这就是获取的行数量。对于INSERT、DELETE、MERGE以及UPDATE 等语句来说，这是所影响的行数量。
关于解析的信息开始两行Misses in library cache during parse和Misses in library cache during execute提供了发生在解析和执行调用阶段的硬解析数量。
如果在执行调用时没有硬解析发生，Misses in library cache during execute这一行将不存在。
接下来是优化器模式以及用于解析SQL语句的用户。
执行计划分为两部分，第一部分称为行源操作(Row Source Operation )，是游标关闭且开启跟踪情况下写到跟踪文件中的执行计划。这意味着如果应用程序不关闭游标而重用它们的话，不会有新的针对重用游标的执行计划写入到跟踪文件中。第二部分，叫做执行计划(Execution Plan)，是由指定了explain参数的TKPROF生成的。既然这是随后生成的，所以和第一部分不一定完全匹配。万一你看到不一致，前者是正确的。
两个执行计划都通过Rows列提供执行计划中每个操作返回的行数（不是处理的--要注意）。
对于每个行源操作来说，可能还会提供如下的运行时统计：
cr是一致性模式下逻辑读出的数据块数。
pr是从磁盘物理读出的数据块数。
pw是物理写入磁盘的数据块数。
time是以微秒表示的总的消逝时间。要注意根据统计得到的值不总是精确的。实际上，为了减少开销，可能用了采样。
cost是操作的评估开销。这个值只有在Oracle 11g才提供。
size是操作返回的预估数据量(字节数)。这个值只有在Oracle 11g才提供。
card是操作返回的预估行数。这个值只有在Oracle 11g才提供。
输出文件的结尾给出了所有关于跟踪文件的信息。首先可以看到跟踪文件名称、版本号、用于这个分析所使用的参数sort的值。然后，给出了所有会话数量与SQL语句数量
摘自：NowOrNever