首先看一个tkprof的报告：
********************************************************************************
SELECT NVL(SUM(PRIMARY_QUANTITY),0)
FROM
MTL_MATERIAL_TRANSACTIONS T WHERE T.ORGANIZATION_ID = :B6 AND
T.SUBINVENTORY_CODE = :B5 AND (T.LOCATOR_ID = :B4 OR (T.LOCATOR_ID IS NULL
AND :B4 IS NULL)) AND T.INVENTORY_ITEM_ID = :B3 AND T.ACCT_PERIOD_ID = :B2
AND T.LAST_UPDATE_DATE <= :B1 AND TRANSACTION_TYPE_ID NOT IN (80,24)
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.00 0 0 0 0
Execute 42624 3.25 2.81 0 0 0 0
Fetch 42624 316.80 7010.98 1903021 10275406 0 42624
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 85249 320.06 7013.79 1903021 10275406 0 42624
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 44 (APPS) (recursive depth: 2)
Rows Row Source Operation
------- ---------------------------------------------------
42624 SORT AGGREGATE (cr=10275406 pr=1903021 pw=0 time=7007015708 us)
17496 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=10275406 pr=1903021 pw=0 time=4941641178 us)
15337814 INDEX RANGE SCAN MTL_MATERIAL_TRANSACTIONS_N1 (cr=207814 pr=48998 pw=0 time=173655190 us)(object id 699742)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT MODE: ALL_ROWS
42624 SORT (AGGREGATE)
17496 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'MTL_MATERIAL_TRANSACTIONS' (TABLE)
15337814 INDEX MODE: ANALYZED (RANGE SCAN) OF
'MTL_MATERIAL_TRANSACTIONS_N1' (INDEX)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1903021 0.96 6795.31
latch: cache buffers chains 7 0.00 0.00
read by other session 469 0.10 1.44
latch: object queue header operation 1 0.00 0.00
********************************************************************************
oracle性能优化：如何讀懂tkprof(zt)
感覺這方面的資料都比較少，目前知道的：（將陸續整理）
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这步。
A、query+current/rows 平均每行所需的block数，太大的话（超过20）SQL语句效率太低
B、Parse count/Execute count parse count应尽量接近1，如果太高的话，SQL会进行不必要的reparse
C、rows Fetch/Fetch Fetch Array的大小，太小的话就没有充分利用批量Fetch的功能，增加了数据在客户端和服务器之间的往返次数。
D、disk/query+current 磁盘IO所占逻辑IO的比例，太大的话有可能是db_buffer_size过小(也跟SQL的具体特性有关)
E、elapsed/cpu 太大表示执行过程中花费了大量的时间等待某种资源
F、cpu Or elapsed 太大表示执行时间过长，或消耗了了大量的CPU时间，应该考虑优化
G、执行计划中的Rows 表示在该处理阶段所访问的行数，要尽量减少
![]()
