table fetch by
rowid 2,094,274 2,484.3 27.7
这是通过索引或者where rowid=语句来取得的行数，当然这个值越大越好。
table fetch continued
row 408 0.5 0.0
这是发生行迁移的行。当行迁移的情况比较严重时，需要对这部分进行优化。 检查行迁移的方法：
1） 运行$ORACLE_HOME/rdbms/admin/utlchain.sql
2） analyze table table_name list chained rows into CHAINED_ROWS 3） select * from CHAINED_ROWS where table_name='table_name';
清除的方法：
方法1：create table table_name_tmp as select * from table_name where rowed in (select head_rowid from chained_rows);
Delete from table_name where rowed in (select head_rowid from chained_rows); Insert into table_name select * from table_name_tmp; 方法2：create table table_name_tmp select * from table_name ; truncate table table_name
insert into table_name select * from table_name_tmp
方法3：用exp工具导出表，然后删除这个表，最后用imp工具导入这表
方法4：alter table table_name move tablespace tablespace_name，然后再重新表的索引 上面的4种方法可以用以消除已经存在的行迁移现象，但是行迁移的产生很多情况下时由于PCT_FREE参数设置的太小所导致，所以需要调整PCT_FREE参数的值。
table scan blocks
gotten 299,249 355.0 4.0 table scan rows
gotten 1,912,851 2,269.1 25.3
table scans (long
tables) 0 0.0 0.0
longtables就是表的大小超过buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一个数据库的大表扫描过多，那么db file scattered read等待事件可能同样非常显著。如果table scans (long tables)的per Trans值大于0，你可能需要增加适当的索引来优化你的SQL语句。
table scans (short
tables) 143,830 170.6 1.9
short tables是指表的长度低于buffer chache 2％（2％是有隐含参数_SMALL_TABLE_THRESHOLD定义的，这个参数在oracle不同的版本中，有不同的含义。在9i和10g中，该参数值定义为2%，在8i中，该参数值为20个blocks，在v7中，该参数为5个blocks）的表。这些表将优先使用全表扫描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的计算方法如下（9i,8K）： (db_cache_size/8192)*2％。 注意：_SMALL_TABLE_THRESHOLD参数修改是相当危险的操作。
transaction
rollbacks 70 0.1 0.0 transaction tables consistent
rea 0 0.0 0.0 transaction tables consistent
rea 0 0.0 0.0
user
calls 345,054 409.3 4.6
user
commits 75,587 89.7 1.0
user
rollbacks 19 0.0 0.0
workarea executions -
optimal 247,121 293.1 3.3 write clones created in
backgroun 0 0.0 0.0 write clones created in
foregroun 25 0.0 0.0
7、I/O统计信息
下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。
在这里主要关注Av Rd(ms)列 (reads per millisecond)的值，一般来说，大部分的磁盘系统的这个值都能调整到14ms以下，oracle认为该值超过20ms都是不必要的。如果该值超过1000ms，基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######，可能是你的系统存在严重的I/O问题，也可能是格式的显示问题。
当出现上面的问题，我们可以考虑以下的方法： 1）优化操作该表空间或者文件的相关的语句。
2）如果该表空间包含了索引，可以考虑压缩索引，是索引的分布空间减小，从而减小I/O。 3）将该表空间分散在多个逻辑卷中，平衡I/O的负载。
4）我们可以通过设置参数DB_FILE_MULTIBLOCK_READ_COUNT来调整读取的并行度，这将提高全表扫描的效率。但是也会带来一个问题，就是oracle会因此更多的使用全表扫描而放弃某些索引的使用。为解决这个问题，我们需要设置另外一个参数OPTIMIZER_INDEX_COST_ADJ=30（一般建议设置10－50）。 关于OPTIMIZER_INDEX_COST_ADJ＝n：该参数是一个百分比值，缺省值为100，可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST Tablespace IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 ->ordered by IOs (Reads + Writes) desc Tablespace ------------------------------ Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ ICD_DXH_IDX 3,869 5 8.6 1.0 36,701 44 1,180 0.1 ICD_DXH_DAT 2,572 3 9.7 1.0 16,545 20 1,076 0.2 UNDOTBS1 16 0 86.9 1.0 19,084 23 283 0.0 ICD_DXH_HISIDX 689 1 30.8 1.0 14,953 18 108 0.0 ICD_DXH_HISDAT 2,756 3 7.9 7.3 1,082 1 3 0.0 PERFSTAT 215 0 6.0 1.0 193 0 0 0.0 SYSTEM 55 0 11.5 5.0 17 0 717 0.1 INDX 1 0 40.0 1.0 1 0 0 0.0 TOOLS 1 0 40.0 1.0 1 0 0 0.0 USERS