写OTune的原因是因为OPMon的输出的信息不够方便我们进行SQL的优化, 在改进后程序输出了以下几方面的信息.
1, 执行信息
- HASH : SQL语句的HASH_VALUE, [HASH: 1116368370]
- EXEC : 在报告期内SQL被执行的次数, [Exec:1]
- GETS : 在报告期内SQL引起的逻辑读的块数及其权重比例, [Gets:378663(4.8)]
- DISK : 在报告期内SQL引起的物理读的块数及其权重比例, [Disk:0(0.0)]
- SORT : 在报告期内SQL引起的内存排序的次数, [Sort:1]
- GET/E : SQL每次执行的平均逻辑读块数, [Get/E:378663]
- DISK/E: SQL每次执行的平均物理读块数, [Disk/E:0]
- ROW/E : SQL每次执行的返回的平均记录数, [Row/E:0]
- PCT : 按(GETS + 15 * DISK)计算的权重比例, 这也是OTune找出SQL的依据, [PCT:4.82]
2, 完整的SQL语句
INSERT INTO STATS$SQLTEXT ( HASH_VALUE , TEXT_SUBSET , PIECE , S
QL_TEXT , ADDRESS , COMMAND_TYPE , LAST_SNAP_ID ) SELECT ST1.HAS
H_VALUE , SS.TEXT_SUBSET , ST1.PIECE , ST1.SQL_TEXT , ST1.ADDRES
S , ST1.COMMAND_TYPE , SS.SNAP_ID FROM V$SQLTEXT ST1 , STATS$SQL
_SUMMARY SS WHERE SS.SNAP_ID = :B3 AND SS.DBID = :B2 AND SS.INST
ANCE_NUMBER = :B1 AND ST1.HASH_VALUE = SS.HASH_VALUE AND ST1.ADD
RESS = SS.ADDRESS AND NOT EXISTS (SELECT 1 FROM STATS$SQLTEXT ST
2 WHERE ST2.HASH_VALUE = SS.HASH_VALUE AND ST2.TEXT_SUBSET = SS.
TEXT_SUBSET ) ORDER BY ST1.HASH_VALUE,SS.TEXT_SUBSET
3, 当前的执行计划
SQL Execute Plan
------------------------------------------------------------------
0 INSERT STATEMENT Optimizer=RULE
1 0 SORT (ORDER BY)
2 1 FILTER
3 2 TABLE ACCESS (BY INDEX ROWID) OF STATS$SQL_SUMMARY
4 3 NESTED LOOPS
5 4 FIXED TABLE (FULL) OF X$KGLNA
6 4 INDEX (RANGE SCAN) OF STATS$SQL_SUMMARY_PK
7 2 INDEX (RANGE SCAN) OF STATS$SQLTEXT_PK
4, 这个SQL中有关表的索引结构
Indexes of table: PERFSTAT.STATS$SQL_SUMMARY
Type UNIQUE INDEX_NAME SEQ COLUMN_NAME ASC
---------- ---------- ---------------------- --- --------------- ----
NORMAL NONUNIQUE STATS$SQL_SUMMARY_PK 1 SNAP_ID ASC
. . . 2 DBID ASC
. . . 3 INSTANCE_NUMBER ASC
. . . 4 HASH_VALUE ASC
. . . 5 TEXT_SUBSET ASC
OTune中输出的报告会按PCT的值降序排列, 默认显示出所有权重在2.5%以上的SQL. 在每一次输出中还包括系统在这一段时间内主要的 Statistics值的变化情况(从V$SYSSTAT获得).