上图为时间统计模型。  sql execute elpased time 时间占主导，即时间耗用主要是在SQL执行上面。  这些SQL的执行对应的等待事件见前面的Top Event，也就是说等待和争用比较突出。  注意：该 时间模型中的指标 存在包含关系，所以存在Time Model Statistics加起来超过100%情形。

2.6、 Operating System Statistics

Operating System Statistics

以上为操作系统统计信息。IO等待的时间为35287厘秒（单位： 百分之一秒）；

2.7、 Foreground Wait Events

Foreground Wait Events

以上，仅仅罗列top6的Foreground Wait Events。 db file sequential read     是个非常常见的 I/O 相关的等待事件，通常显示与单个数据块相关的读取操作。在大多数的情况下，读取一个 索引块或者通过索引读取一个数据块时，都会记录这个等待。这个等待事件有 3 个参数 P1、 P2、 P3，其中 P1 代表 Oracle 要读取的文件的绝对文件号， P2 代表 Oracle 从这个文件中开始读取的起始数据块块号， P3 代表读取的 BLOCK数量，通常这个值为 1，表明是单个 BLOCK 被读取。db file sequential read 等待时间是由于执行对索引、回滚（undo）段和表（当借助rowid来访问）、控制文件和数据文件头的单块读操作SQL语句（用户和递归）引起的。对于这些对象的物理I/O请求是很正常的，因此db file sequential read等待的存在不是一定意味库或应用出错了。  如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，没有正确地使用驱动表；或者可能索引的使用存在问题，并非索引总是最好的选择。 db file sequential read 的优化方法：     1）从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；     2）优化sql语句，减少不必要的块读取； log file sync                 当一个用户提交(commits)或者回滚(rollback)时，session的redo信息需要写出到redo logfile中。用户进程将通知LGWR执行写出操作，LGWR完成任务以后会通知用户进程，这个等待事件就是指用户进程等待LGWR的写完成通知。对于回滚操作，该事件记录从用户发出rollback命令到回滚完成的时间。如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁。针对该问题，可以关注 log file parallel write 等待事件，通过 user commits,user rollback等统计信息可以用于观察提交或回滚次数。 log file sync 的优化方法：     1）提高LGWR性能，尽量使用快速磁盘，不要把redo log file 存放在raid 5的磁盘上；     2）应用尽量使用批量提交，对于已有应用，改造工作量会比较大，而且很多场景未必适应；     3）根据业务场景，适当使用NOLOGGING/UNRECOVERABLE等选项配合使用； library cache lock          该等待事件可以参考下面的附三； read by other session     等待事件其实是oracle IO问题一个比较尴尬的场景，其原理是多个会话并发将同一数据块从磁盘读入SGA的data buffer cache中 ，但ORACLE同一时间只允许一个会话从磁盘将同一数据块读入SGA，在并发情况下其它session必须等待，因此就有了read by other session等待事件，结合 db file sequential read 这个等待事件原理，基本上可以断定，系统发生了高并发查询，并且从log file sync等待事件来看，系统发生了频率的提交操作，导致数据库日志频繁同步。需要查找AWR报告中跟I/O有关的SQL语句，进行优化。 library cache: mutex X      在Oracle11g中，mutex X替代了之前的library cache latch，主要作用是在hash bucket中定位handle时使用（比如SQL 硬解析时，需要往hash bucket中新增一个cursor时，需要library cache latch） 。mutex是11g中采用的轻量级锁，替代latch（更轻量，更细粒度）。其中mutex X表示eXclusive模式，如果是mutex s则是共享模式。 Library cache: mutex 等待事件产生常见原因：

enq: TX - row lock contention     通常是Application级别的问题。其中的enq是enquence的简写（enquence是协调访问数据库资源的内部锁）。所有以“enq:”打头的等待事件都表示这个会话正在等待另一个会话持有的内部锁释放，它的名称格式是 enq:enqueue_type - related_details。这里的enqueue_type是TX，related_details是row lock contention。数据库动态性能视图v$event_name提供所有以“enq:”开头的等待事件的列表。 enq: TX - row lock contention 等待事件产生的三种情况如下：

三、附上Oracle的SQL解析过程介绍

每一个sql被执行之前，会先将sql语句经过ascii转换，通过hash算法获得对应的hash_value， 根据hash_value先到library cache的hash buckets 中查找parent cursor，这就需要先获得library cache latch；找到parent cursor后，就会去查找对应的child cursor,当发现无法找到时，就会释放library cache latch，获得share pool latch分配空间给硬解析后所产生的执行计划；然后再次获得library cache latch并把新生成的执行计划放入share pool，转入library cache pin+lock（null模式）开始执行sql。library cache latch 的个数有限（与CPU_COUNT参数相关），当数据库中出现大量硬解析的时候，某一个sql无法得到library cache latch就会开始spin，达到spin count后还没得到，就会开始sleep,达到sleep时间后醒来，再次试图获得library cache latch，在spin得不到，则继续sleep…依此类推。通过持有 library cache latch获得父游标里面包含的sql文本，随后生成子游标包含执行计划和解析树，执行计划在heap 6中，解析完毕之后sql开始执行，最终反馈结果给客户端。 下图是经典的library cache结构图。 我们可以看到在每一个library cache object handle上都存在4个链表，它们分别是lock owners，lock waiters，Pin owners，Pin waiters。所以实际上library cache object handle你可以把它看成是library cache lock和library cache pin所保护的resource。而向lock owners和lock waiters里添加/修改一个library cache lock时是需要先持有Child library cache lock；向Pin owners和Pin waiters里添加/修改一个library cache pin时是需要先持有Child library cache pin。

无论是硬解析还是软解析，在扫描/修改 library cache object handle 链表的时候是需要先持有 Child library cache；另外，硬解析还涉及到要在shared pool 里分配内存，所以硬解析还会持有 Child shared pool。 下面，将逐个解释各种解析的原理及举例说明。 硬解析过程：

1.SQL的语法、语义及权限检查；

2.查询转换（通过应用各种不同的转换技巧，会生成语义上等同的新的SQL语句，如count(1)会转为count(*)）；

3.根据统计信息生成执行计划（根据CBO/LBO算法，找出成本最低的路径，这一步比较耗时）；

4.将游标信息（执行计划）保存到库缓存 library cache。 软解析过程：

1.SQL的语法、语义及权限检查；

2.将整条SQL hash后从库缓存library cache中查找对应的执行计划。

软解析对比硬解析省了三个步骤。 软软解析过程： 要完全理解软软解析先要理解游标的概念，当执行SQL时，首先要打开游标，执行完成后，要关闭游标，游标可以理解为SQL语句的一个句柄。 在执行软软解析之前，首先要进行软解析，MOS上说执行3次的SQL语句会把游标缓存到PGA，这个游标一直开着，当再有相同的SQL执行时，则跳过解析的所有过程直接去取执行计划。 解析演示举例

SQL> drop table test purge; SQL> alter system flush shared_pool; SQL> create table test as select * from dba_objects where 1<>1; SQL> exec dbms_stats.gather_table_stats(user,'test');

硬解析： SQL> select * from test where object_id=20; 未选定行 SQL> select * from test where object_id=30; 未选定行 SQL> select * from test where object_id=40; 未选定行 SQL> select * from test where object_id=50; 未选定行

软解析： SQL> var oid number; SQL> exec :oid:=20; SQL> select * from test where object_id=:oid; 未选定行 SQL> exec :oid:=30; SQL> select * from test where object_id=:oid; 未选定行 SQL> exec :oid:=40; SQL> select * from test where object_id=:oid; 未选定行 SQL> exec :oid:=50; SQL> select * from test where object_id=:oid; 未选定行 软软解析： SQL> begin for i in 1..4 loop execute immediate 'select * from test where object_id=:i' using i; end loop; end; / SQL> col sql_text format a40 SQL> select sql_text,s.PARSE_CALLS,loads,executions from v$sql s where sql_text like 'select * from test where object_id%' order by 1,2,3,4; SQL_TEXT                         PARSE_CALLS     LOADS     EXECUTIONS ---------------------------------------- ----------- ---------- ---------- select * from test where object_id=20         1     1     1 select * from test where object_id=30         1     1     1 select * from test where object_id=40         1     1     1 select * from test where object_id=50         1     1     1 select * from test where object_id=:i           1     1     4 select * from test where object_id=:oid       4     1     4

可以看到软解析与软软解析相比，软软解析只是解析一次。

字段解释： PARSE_CALLS 解析的次数;

LOADS 硬解析的次数;

EXECUTIONS 执行的次数;