有些等待事件经常记错，整理下：


Parse CPU to Parse Elapsd

 解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。

Non-Parse CPU

 SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。

SQL ordered by Parse Calls

  • Total Parse Calls: 182,780

  • Captured SQL account for 99.0% of Total

在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。

SELECT *

FROM(SELECTSUBSTR(sql_text,1,40)sql,

                parse_calls,

                executions,

                hash_value,

                address

FROMv$sqlarea

WHEREparse_calls >0

ORDERBYparse_calls DESC)

WHEREROWNUM<=10;


Tablespace IO Stats

  • ordered by IOs (Reads + Writes) desc

Tablespace

Reads

Av Reads/s

Av Rd(ms)

Av Blks/Rd

Writes

Av Writes/s

Buffer Waits

Av Buf Wt(ms)

ICCIDAT01

67,408

14

3.76

3.17

160,261

34

6

0.00

UNDOTBS1

10

0

12.00

1.00

57,771

12

625

0.02

TEMP

15,022

3

8.74

7.24

3,831

1

0

0.00

USERS

68

0

5.44

1.00

971

0

0

0.00

SYSAUX

263

0

5.48

1.00

458

0

0

0.00

SYSTEM

32

0

5.94

1.00

158

0

3

23.33

UNDOTBS2

6

0

16.67

1.00

6

0

0

0.00

显示每个表空间的I/O统计。根据Oracle经验，Av Rd(ms) [Average Readsin milliseconds]不应该超过30，否则认为有I/O争用。


IO Stats

  • Tablespace     IO Stats

  • File     IO Stats

Back to Top


通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦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）。