3 TOP SQL
TOP SQL 的数据部分来源于 dba_hist_sqlstat
3-1 SQL ordered by Elapsed Time ，按照SQL消耗的时间来排列TOP SQL

SQL ordered by Elapsed Time Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100-> %Total - Elapsed Time as a percentage of Total DB time-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Captured SQL account for 53.9% of Total DB Time (s): 883,542-> Captured PL/SQL account for 0.5% of Total DB Time (s): 883,542 Elapsed Elapsed Time Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id---------------- -------------- ------------- ------ ------ ------ ------------- 181,411.3 38,848 4.67 20.5 .0 .1 g0yc9szpuu068

注意对于PL/SQL，SQL Statistics不仅会体现该PL/SQL的执行情况，还会包括该PL/SQL包含的SQL语句的情况。如上例一个TOP PL/SQL执行了448s，而这448s中绝大多数是这个PL/SQL下的一个SQL执行500次耗费的。则该TOP PL/SQL和TOP SQL都上榜，一个执行一次耗时448s，一个执行500次耗时448s。 如此情况则Elapsed Time加起来可能超过100%的Elapsed Time，这是正常的。对于鹤立鸡群的SQL很有必要一探究竟，跑个@?/rdbms/admin/awrsqrpt看看吧！
Elapsed Time (s): 该SQL累计运行所消耗的时间，Executions : 该SQL在快照时间内 总计运行的次数 ； 注意， 对于在快照时间内还没有执行完的SQL 不计为1一次，所以如果看到executions=0而 又是TOP SQL，则很有可能是因为该SQL 运行较旧还没执行完，需要特别关注一下。

Elapsed Time per Exec (s)：平均每次执行该SQL耗费的时间 ， 对于OLTP类型的SELECT/INSERT/UPDATE/DELETE而言平均单次执行时间应当非常短，如0.1秒 或者更短才能满足其业务需求，如果这类轻微的OLTP操作单次也要几秒钟的话，是无法满足对外业务的需求的； 例如你在ATM上提款，并不仅仅是对你的账务库的简单UPDATE，而需要在类似风险控制的前置系统中记录你本次的流水操作记录，实际取一次钱可能要有几十乃至上百个OLTP类型的语句被执行，但它们应当都是十分快速的操作； 如果这些操作也变得很慢，则会出现大量事务阻塞，系统负载升高，DB TIME急剧上升的现象。 对于OLTP数据库而言 如果执行计划稳定，那么这些OLTP操作的性能应当是铁板钉钉的，但是一旦某个因素 发生变化，例如存储的明显变慢、内存换页的大量出现时 则上述的这些transaction操作很可能成数倍到几十倍的变慢，这将让此事务系统短期内不可用。对于维护操作，例如加载或清除数据，大的跑批次、报表而言 Elapsed Time per Exec (s)高一些是正常的。%Total 该SQL所消耗的时间占总的DB Time的百分比， 即 (SQL Elapsed Time / Total DB TIME)% CPU 该SQL 所消耗的CPU 时间 占 该SQL消耗的时间里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，该指标说明了该语句是否是CPU敏感的%IO 该SQL 所消耗的I/O 时间 占 该SQL消耗的时间里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，该指标说明了该语句是否是I/O敏感的SQL Id : 通过计算SQL 文本获得的SQL_ID ，不同的SQL文本必然有不同的SQL_ID， 对于10g~11g而言 只要SQL文本不变那么在数据库之间 该SQL 对应的SQL_ID应当不不变的， 12c中修改了SQL_ID的计算方法
Captured SQL account for 53.9% of Total DB Time (s) 对于不绑定变量的应用来说Top SQL有可能失准，所以要参考本项
3-2 SQL ordered by CPU Time

SQL ordered by CPU Time Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> %Total - CPU Time as a percentage of Total DB CPU-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Captured SQL account for 34.9% of Total CPU Time (s): 20,649-> Captured PL/SQL account for 0.5% of Total CPU Time (s): 20,649 CPU CPU per Elapsed Time (s) Executions Exec (s) %Total Time (s) %CPU %IO SQL Id---------- ------------ ---------- ------ ---------- ------ ------ ------------- 1,545.0 1,864,424 0.00 7.5 4,687.8 33.0 65.7 8g6a701j83c8qModule: MZIndexerSELECT t0.BOOLEAN_VALUE, t0.CLASS_CODE, t0.CREATED, t0.END_DATE, t0.PRODUCT_ATTRIBUTE_ID, t0.LAST_MODIFIED, t0.OVERRIDE_FLAG, t0.PRICE, t0.PRODUCT_ATTRIBUTE_TYPE_ID, t0.PRODUCT_ID, t0.PRODUCT_PUB_RELEASE_TYPE_ID, t0.PRODUCT_VOD_TYPE_ID, t0.SAP_PRODUCT_ID, t0.START_DATE, t0.STRING_VALUE FROM mz_product_attribute t0 WHER

CPU TIME : 该SQL 在快照时间内累计执行所消耗的CPU 时间片，单位为sExecutions : 该SQL在快照时间内累计执行的次数CPU per Exec (s) ：该SQL 平均单次执行所消耗的CPU时间 ， 即 ( SQL CPU TIME / SQL Executions )%Total : 该SQL 累计消耗的CPU时间 占 该时段总的 DB CPU的比例， 即 ( SQL CPU TIME / Total DB CPU)% CPU 该SQL 所消耗的CPU 时间 占 该SQL消耗的时间里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，该指标说明了该语句是否是CPU敏感的%IO 该SQL 所消耗的I/O 时间 占 该SQL消耗的时间里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，该指标说明了该语句是否是I/O敏感的

3-3 Buffer Gets SQL ordered by Gets

SQL ordered by Gets DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> %Total - Buffer Gets as a percentage of Total Buffer Gets-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Buffer Gets: 2,021,476,421-> Captured SQL account for 68.2% of Total Buffer Gets Elapsed Gets Executions per Exec %Total Time (s) %CPU %IO SQL Id----------- ----------- ------------ ------ ---------- ------ ------ -----------4.61155E+08 1,864,424 247.3 22.8 4,687.8 33.0 65.7 8g6a701j83c
注意 buffer gets 逻辑读是消耗CPU TIME的重要源泉， 但并不是说消耗CPU TIME的只有buffer gets。 大多数情况下 SQL order by CPU TIME 和 SQL order by buffers gets 2个部分的TOP SQL 及其排列顺序都是一样的，此种情况说明消耗最多buffer gets的 就是消耗最多CPU 的SQL ，如果我们希望降低系统的CPU使用率，那么只需要调优SQL 降低buffer gets 即可。但也并不是100%的情况都是如此， CPU TIME的消耗者 还包括 函数运算、PL/SQL 控制、Latch /Mutex 的Spin等等， 所以SQL order by CPU TIME 和 SQL order by buffers gets 2个部分的TOP SQL 完全不一样也是有可能的， 需要因地制宜来探究到底是什么问题导致的High CPU，进而裁度解决之道。
Buffer Gets : 该SQL在快照时间内累计运行所消耗的buffer gets，包括了consistent read 和 current readExecutions : 该SQL在快照时间内累计执行的次数Gets per Exec : 该SQL平均单次的buffer gets ， 对于事务型transaction操作而言 一般该单次buffer gets小于2000% Total 该SQL 累计运行所消耗的buffer gets占 总的db buffer gets的比率， (SQL buffer gets / DB total buffer gets)

3-4 Physical Reads SQL ordered by Reads

SQL ordered by Reads DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> %Total - Physical Reads as a percentage of Total Disk Reads-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Disk Reads: 56,839,035-> Captured SQL account for 34.0% of Total Physical Reads Elapsed Reads Executions per Exec %Total Time (s) %CPU %IO SQL Id----------- ----------- ---------- ------ ---------- ------ ------ ------------- 9,006,163 1 9.0062E+06 15.8 720.9 5.9 80.9 4g36tmp70h185Physical reads : 该SQL累计运行所消耗的物理读Executions : 该SQL在快照时间内累计执行的次数Reads per Exec : 该SQL 单次运行所消耗的物理读， (SQL Physical reads/Executions) ， 对于OLTP transaction 类型的操作而言单次一般不超过100%Total : 该SQL 累计消耗的物理读 占 该时段总的 物理读的比例， 即 ( SQL physical read / Total DB physical read )

3-5 Executions SQL ordered by Executions

SQL ordered by Executions Snaps: 70719-70723-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Executions: 48,078,147-> Captured SQL account for 50.4% of Total Elapsed Executions Rows Processed Rows per Exec Time (s) %CPU %IO SQL Id------------ --------------- -------------- ---------- ------ ------ ----------- 6,327,963 11,249,645 1.8 590.5 47.8 52.7 1avv7759j8r
按照 执行次数来排序的话，也是性能报告对比时一个重要的参考因素，因为如果TOP SQL的执行次数有明显的增长，那么 性能问题的出现也是意料之中的事情了。 当然执行次数最多的，未必便是对性能影响最大的TOP SQL
Executions : 该SQL在快照时间内累计执行的次数Rows Processed： 该SQL在快照时间内累计执行所处理的总行数Rows per Exec：　SQL平均单次执行所处理的行数， 这个指标在诊断一些 数据问题造成的SQL性能问题时很有用

3-6 Parse Calls SQL ordered by Parse Calls

SQL ordered by Parse Calls Snaps: 70719-70723-> Total Parse Calls: 2,160,124-> Captured SQL account for 58.3% of Total % Total Parse Calls Executions Parses SQL Id------------ ------------ --------- ------------- 496,475 577,357 22.98 d07gaa3wntdff

Parse Calls : 解析调用次数， 与上文的 Load Profile中的Parse 数一样 包括 软解析soft parse和硬解析hard parseExecutions : 该SQL在快照时间内累计执行的次数%Total Parses : 本SQL 解析调用次数 占 该时段数据库总解析次数的比率， 为 (SQL Parse Calls / Total DB Parse Calls)

3-7 SQL ordered by Sharable Memory

SQL ordered by Sharable Memory Snaps: 70719-70723-> Only Statements with Sharable Memory greater than 1048576 are displayedSharable Mem (b) Executions % Total SQL Id---------------- ------------ -------- ------------- 8,468,359 39 0.08 au89sasqfb2ynModule: MZContentBridgeSELECT t0.ASPECT_RATIO, t0.CREATED, t0.FILE_EXTENSION, t0.HEIGHT, t0.VIDEO_FILE_DIMENSIONS_ID, t0.LAST_MODIFIED, t0.NAME, t0.WIDTH FROM MZ_VIDEO_FILE_DIMENSIONS t0 WHERE (t0.HEIGHT = :1 AND t0.WIDTH = :2 )

SQL ordered by Sharable Memory , 一般该部分仅列出Sharable Mem (b)为1 MB以上的SQL 对象 (Only Statements with Sharable Memory greater than 1048576 are displayed) 数据来源是 DBA_HIST_SQLSTAT.SHARABLE_MEMShareable Mem(b): SQL 对象所占用的共享内存使用量Executions : 该SQL在快照时间内累计执行的次数%Total : 该SQL 对象锁占共享内存 占总的共享内存的比率

3-8 SQL ordered by Version Count

Version Count Oracle中的执行计划可以是多版本的，即对于同一个SQL语句有多个不同版本的执行计划，这些执行计划又称作子游标， 而一个SQL语句的文本可以称作一个父游标。 一个父游标对应多个子游标，产生不同子游标的原因是 SQL在被执行时无法共享之前已经生成的子游标， 原因是多种多样的，例如 在本session中做了一个优化器参数的修改 例如optimizer_index_cost_adj 从100 修改到99，则本session的优化环境optimizer env将不同于之前的子游标生成环境，这样就需要生成一个新的子游标，例如：

SQL> create table emp as select * from scott.emp;Table created.SQL> select * from emp where empno=1;no rows selectedSQL> select /*+ MACLEAN */ * from emp where empno=1;no rows selectedSQL> select SQL_ID,version_count from V$SQLAREA WHERE SQL_TEXT like '%MACLEAN%' and SQL_TEXT not like '%like%';SQL_ID VERSION_COUNT------------- -------------bxnnm7z1qmg26 1SQL> select count(*) from v$SQL where SQL_ID='bxnnm7z1qmg26'; COUNT(*)---------- 1SQL> alter session set optimizer_index_cost_adj=99;Session altered.SQL> select /*+ MACLEAN */ * from emp where empno=1;no rows selectedSQL> select SQL_ID,version_count from V$SQLAREA WHERE SQL_TEXT like '%MACLEAN%' and SQL_TEXT not like '%like%';SQL_ID VERSION_COUNT------------- -------------bxnnm7z1qmg26 2SQL> select count(*) from v$SQL where SQL_ID='bxnnm7z1qmg26'; COUNT(*)---------- 2SQL> select child_number ,OPTIMIZER_ENV_HASH_VALUE,PLAN_HASH_VALUE from v$SQL where SQL_ID='bxnnm7z1qmg26';CHILD_NUMBER OPTIMIZER_ENV_HASH_VALUE PLAN_HASH_VALUE------------ ------------------------ --------------- 0 3704128740 3956160932 1 3636478958 3956160932

可以看到上述 演示中修改optimizer_index_cost_adj=99 导致CBO 优化器的优化环境发生变化， 表现为不同的OPTIMIZER_ENV_HASH_VALUE，之后生成了2个子游标，但是这2个子游标的PLAN_HASH_VALUE同为3956160932，则说明了虽然是不同的子游标但实际子游标里包含了的执行计划是一样的； 所以请注意 任何一个优化环境的变化 (V$SQL_SHARED_CURSOR)以及相关衍生的BUG 都可能导致子游标无法共享，虽然子游标无法共享但这些子游标扔可能包含完全一样的执行计划，这往往是一种浪费。注意V$SQLAREA.VERSION_COUNT 未必等于select count(*) FROM V$SQL WHERE SQL_ID=” ，即 V$SQLAREA.VERSION_COUNT 显示的子游标数目 未必等于当前实例中还存有的子游标数目， 由于shared pool aged out算法和其他一些可能导致游标失效的原因存在，所以子游标被清理掉是很常见的事情。 V$SQLAREA.VERSION_COUNT只是一个计数器，它告诉我们曾经生成了多少个child cursor，但不保证这些child 都还在shared pool里面。此外可以通过v$SQL的child_number字段来分析该问题，如果child_number存在跳号则也说明了部分child被清理了。

子游标过多的影响， 当子游标过多(例如超过3000个时),进程需要去扫描长长的子游标列表child cursor list以找到一个合适的子游标child cursor，进而导致cursor sharing 性能问题 现大量的Cursor: Mutex S 和 library cache lock等待事件。关于子游标的数量控制，可以参考《11gR2游标共享新特性带来的一些问题以及_cursor_features_enabled、_cursor_obsolete_threshold和106001 event》。
Executions : 该SQL在快照时间内累计执行的次数
Hash Value : 共享SQL 的哈希值
Only Statements with Version Count greater than 20 are displayed 注意该环节仅列出version count > 20的语句

3-9 Cluster Wait Time SQL ordered by Cluster Wait Time

SQL ordered by Cluster Wait Time DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> %Total - Cluster Time as a percentage of Total Cluster Wait Time-> %Clu - Cluster Time as a percentage of Elapsed Time-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Only SQL with Cluster Wait Time > .005 seconds is reported-> Total Cluster Wait Time (s): 525,480-> Captured SQL account for 57.2% of Total Cluster Elapsed Wait Time (s) Executions %Total Time(s) %Clu %CPU %IO SQL Id-------------- ------------ ------ ---------- ------ ------ ------ ------------- 132,639.3 38,848 25.2 181,411.3 73.1 .0 .1 g0yc9szpuu068

Only SQL with Cluster Wait Time > .005 seconds is reported 这个环节仅仅列出Cluster Wait Time > 0.005 s的SQL该环节的数据主要来源 于 DBA_HIST_SQLSTAT.CLWAIT_DELTA Delta value of cluster wait timeCluster Wait Time : 该SQL语句累计执行过程中等待在集群等待上的时间，单位为秒， 你可以理解为 当一个SQL 执行过程中遇到了gc buffer busy、gc cr multi block request 之类的Cluster等待，则这些等待消耗的时间全部算在 Cluster Wait Time里。Executions : 该SQL在快照时间内累计执行的次数%Total: 该SQL所消耗的Cluster Wait time 占 总的Cluster Wait time的比率， 为(SQL cluster wait time / DB total cluster Wait Time)%Clu: 该SQL所消耗的Cluster Wait time 占该SQL 总的耗时的比率，为(SQL cluster wait time / SQL elapsed Time),该指标说明了该语句是否是集群等待敏感的% CPU 该SQL 所消耗的CPU 时间 占 该SQL消耗的时间里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，该指标说明了该语句是否是CPU敏感的%IO 该SQL 所消耗的I/O 时间 占 该SQL消耗的时间里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，该指标说明了该语句是否是I/O敏感的

4 Instance Activity Stats

Instance Activity Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> Ordered by statistic nameStatistic Total per Second per Trans-------------------------------- ------------------ -------------- -------------Batched IO (bound) vector count 450,449 124.6 1.8Batched IO (full) vector count 5,485 1.5 0.0Batched IO (space) vector count 1,467 0.4 0.0Batched IO block miss count 4,119,070 1,139.7 16.7Batched IO buffer defrag count 39,710 11.0 0.2Batched IO double miss count 297,357 82.3 1.2Batched IO same unit count 1,710,492 473.3 7.0Batched IO single block count 329,521 91.2 1.3Batched IO slow jump count 47,104 13.0 0.2Batched IO vector block count 2,069,852 572.7 8.4Batched IO vector read count 262,161 72.5 1.1Block Cleanout Optim referenced 37,574 10.4 0.2CCursor + sql area evicted 1,457 0.4 0.0...............
Instance Activity Stats 的数据来自于 DBA_HIST_SYSSTAT，DBA_HIST_SYSSTAT来自于V$SYSSTAT。这里每一个指标都代表一种数据库行为的活跃度，例如redo size 是指生成redo的量，sorts (disk) 是指磁盘排序的次数，table scans (direct read) 是指直接路径扫描表的次数。虽然这些指标均只有Total、per Second每秒、 per Trans每事务 三个维度，但对诊断问题十分有用。我们来举几个例子：1、 例如当 Top Event 中存在direct path read为Top 等待事件， 则需要分清楚是对普通堆表的direct read还是由于大量LOB读造成的direct path read， 这个问题可以借助 table scans (direct read)、table scans (long tables)、physical reads direct 、physical reads direct (lob) 、physical reads direct temporary几个指标来分析， 假设 physical reads direct >> 远大于 physical reads direct (lob)+physical reads direct temporary ， 且有较大的table scans (direct read)、table scans (long tables) (注意这2个指标代表的是 扫描表的次数 不同于上面的phsical reads 的单位为 块数*次数)， 则说明了是 大表扫描引起的direct path read。

2、 例如当 Top Event中存在enq Tx:index contention等待事件， 则需要分析root node splits 、branch node splits 、leaf node 90-10 splits 、leaf node splits 、failed probes on index block rec 几个指标

3、系统出现IO类型的等待事件为TOp Five 例如 db file sequential/scattered read ，我们需要通过AWR来获得系统IO吞吐量和IOPS:physical read bytes 主要是应用造成的物理读取(Total size in bytes of all disk reads by application activity (and not other instance activity) only.) 而physical read total bytes则包括了 rman备份恢复 和后台维护任务所涉及的物理读字节数，所以我们在研究IO负载时一般参考 physical read total bytes；以下4对指标均存在上述的关系

[table=98%]
[td=243]physical read bytes[td=289]physical read total bytes[td=205]物理读的吞吐量/秒
physical read IO requestsphysical read total IO requests物理读的IOPS
physical write bytesphysical write total bytes物理写的吞吐量/秒
physical write IO requestsphysical write total IO requests物理写的IOPS

总的物理吞吐量/秒=physical read total bytes+physical write total bytes总的物理IOPS= physical read total IO requests+ physical write total IO requests
IO的主要指标 吞吐量、IOPS和延迟 均可以从AWR中获得了， IO延迟的信息可以从 User I/O的Wait Class Avg Wait time获得，也可以参考11g出现的IOStat by Function summary

Instance Activity Stats有大量的指标，但是对于这些指标的介绍 没有那一份文档有完整详尽的描述，即便在Oracle原厂内部要没有(或者是Maclean没找到)，实际是开发人员要引入某一个Activity Stats是比较容易的，并不像申请引入一个新后台进程那样麻烦，Oracle对于新版本中新后台进程的引入有严格的要求，但Activity Stats却很容易，往往一个one-off patch中就可以引入了，实际上Activity Stats在源代码层仅仅是一些计数器。’较为基础的statistics，大家可以参考官方文档的Statistics Descriptions描述，地址在这里。
对于深入的指标 例如 “Batched IO (space) vector count”这种由于某些新特性被引入的，一般没有很详细的材料，需要到源代码中去阅读相关模块才能总结其用途，对于这个工作一般原厂是很延迟去完成的，所以没有一个完整的列表。 如果大家有对此的疑问，请去t.askmaclean.com 发一个帖子提问。

Instance Activity Stats - Absolute Values Snaps: 7071-> Statistics with absolute values (should not be diffed)Statistic Begin Value End Value-------------------------------- --------------- ---------------session pga memory max 1.157882826E+12 1.154290304E+12session cursor cache count 157,042,373 157,083,136session uga memory 5.496429019E+14 5.496775467E+14opened cursors current 268,916 265,694workarea memory allocated 827,704 837,487logons current 2,609 2,613session uga memory max 1.749481584E+13 1.749737418E+13session pga memory 4.150306913E+11 4.150008177E+11

Instance Activity Stats – Absolute Values是显示快照 起点 和终点的一些指标的绝对值[list]
[*]logon current 当前时间点的登录数
[*]opened cursors current 当前打开的游标数
[*]session cursor cache count 当前存在的session缓存游标数

Instance Activity Stats - Thread ActivityDB/Inst: G10R25/G10R25 Snaps: 3663-3-> Statistics identified by '(derived)' come from sources other than SYSSTAT Statistic Total per Hour -------------------------------- ------------------ --------- log switches (derived) 17 2,326.47

log switches (derived) 日志切换次数 ， 见 《理想的在线重做日志切换时间是多长？》

5 IO 统计
5-1 Tablespace IO Stats 基于表空间分组的IO信息

Tablespace IO Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> ordered by IOs (Reads + Writes) descTablespace------------------------------ Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)-------------- ------- ------- ------- ------------ -------- ---------- -------DATA_TS 17,349,398 4,801 2.3 1.5 141,077 39 4,083,704 5.8INDEX_TS 9,193,122 2,544 2.0 1.0 238,563 66 3,158,187 46.1UNDOTBS1 1,582,659 438 0.7 1.0 2 0 12,431 69.0
reads : 指 该表空间上发生的物理读的次数(单位不是块，而是次数)Av Reads/s : 指该表空间上平均每秒的物理读次数 (单位不是块，而是次数)Av Rd(ms): 指该表空间上每次读的平均读取延迟
Av Blks/Rd: 指该表空间上平均每次读取的块数目，因为一次物理读可以读多个数据块；如果Av Blks/Rd>>1 则可能系统有较多db file scattered read 可能是诊断FULL TABLE SCAN或FAST FULL INDEX SCAN，需要关注table scans (long tables) 和index fast full scans (full) 2个指标
Writes : 该表空间上发生的物理写的次数 ; 对于那些Writes总是等于0的表空间 不妨了解下是否数据为只读，如果是可以通过read only tablespace来解决 RAC中的一些性能问题。Av Writes/s : 指该表空间上平均每秒的物理写次数buffer Waits: 该表空间上发生buffer busy waits和read by other session的次数( 9i中buffer busy waits包含了read by other session)。Av Buf Wt(ms): 该表空间上发生buffer Waits的平均等待时间，单位为ms

5-2 File I/O

File IO Stats Snaps: 70719-70723-> ordered by Tablespace, FileTablespace Filename------------------------ ---------------------------------------------------- Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)-------------- ------- ------- ------- ------------ -------- ---------- -------AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data2/amg_album_idx_ts01.dbf 23,298 6 0.6 1.0 2 0 0 0.0AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data3/amg_album_idx_ts02.dbf 3,003 1 0.6 1.0 2 0 0 0.0
Tablespace 表空间名FileName 数据文件的路径Reads: 该数据文件上累计发生过的物理读次数，不是块数Av Reads/s: 该数据文件上平均每秒发生过的物理读次数，不是块数Av Rd(ms): 该数据文件上平均每次物理读取的延迟，单位为msAv Blks/Rd: 该数据文件上平均每次读取涉及到的块数，OLTP环境该值接近 1Writes : 该数据文件上累计发生过的物理写次数，不是块数Av Writes/s: 该数据文件上平均每秒发生过的物理写次数，不是块数buffer Waits: 该数据文件上发生buffer busy waits和read by other session的次数( 9i中buffer busy waits包含了read by other session)。Av Buf Wt(ms): 该数据文件上发生buffer Waits的平均等待时间，单位为ms
若某个表空间上有较高的IO负载，则有必要分析一下 是否其所属的数据文件上的IO 较为均匀 还是存在倾斜， 是否需要结合存储特征来 将数据均衡分布到不同磁盘上的数据文件上，以优化 I/O