通过案例学调优之--Oracle Time Model（时间模型）

数据库时间 

      优化不仅仅是缩短等待时间。优化旨在缩短最终用户响应时间和（或）尽可能减少每个请求占用的平均资源。有时这些目标可同时实现，而有时则需要进行折衷（如在并行查询时）。通常可以认为，优化就是避免以浪费的方式占用或保留资源。  

      对数据库发出的任何请求都由两个不同的段组成：等待时间（数据库等待时间）和服务时间（数据库 CPU 时间）。等待时间是各种数据库实例资源的所有等待时间的总和。CPU 时间是实际处理请求时消耗的时间的总和。这些时间不一定由一个等待时间和一个 CPU 时间块组成。通常，进程会等待数据库资源较短时间，然后在 CPU 上短暂运行，并重复执行这一系列过程。 

优化包括缩短或消除等待时间以及缩短 CPU 时间。此定义适用于任何应用程序类型、联机事务处理 (OLTP) 或数据仓库 (DW)。  

注：非常繁忙的系统的数据库 CPU 时间较长，这会增大其它时间。 

CPU 时间和等待时间优化思维 

     优化系统时，应将 CPU 时间与系统的等待时间进行比较，这一点很重要。通过将 CPU 时间与等待时间进行比较，可以确定用于有效工作的响应时间，以及用于等待可能由其它进程占用的资源的时间。通常情况下，与等待时间占主导地位的系统相比，CPU 时间占主导地位的系统需要的优化较少。但是，SQL 语句编写不佳也可能导致高 CPU 使用率。 

虽然随着系统负载的增加，等待时间与 CPU 时间的比值会不断增大，但等待时间的迅速增加是争用的迹象，必须解决这一问题才能获得良好的可扩展性。 

     增加的等待时间表明发生争用时，在节点中增加 CPU 或在集群中增加节点的作用将非常有限。相反，CPU 时间的分配比例不会随着负载增大而明显减小的系统，可扩展性会更好，并且最有可能通过添加 CPU 或 Real Application Clusters (RAC) 实例受益。 

注： 自动工作量资料档案库 (AWR) 和 Statspack 报表在“Top 5 Event（前 5 个事件）”部分显示 CPU 时间排前 5 位的事件的 CPU 时间和等待时间。

时间模型：概览 

       许多组件参与 Oracle DB 系统的优化，每个组件拥有自己的统计信息集。如何评估优化措施预计为总体系统带来的好处？例如，如果将内存从缓冲区高速缓存移至共享池，是否可以提高总体性能？整体查看系统时，时间是比较各个组件的唯一常用标尺。在 Oracle DB 服务器中，大多数建议统计信息都会以时间为单位报告其结果。还有称为“时间模型统计信息”的统计信息，显示为 V$SYS_TIME_MODEL 和 V$SESS_TIME_MODEL 性能视图。此工具帮助 Oracle DB 服务器确定对数据库操作的定量影响。 

      时间模型统计信息中最重要的是数据库时间。此统计信息代表数据库调用花费的总时间，并指示总的实例工作量，它是未等待“空闲等待事件”的所有会话（非空闲用户会话）的 CPU 时间和等待时间的总和。 

     优化 Oracle 数据库系统的目标可以表述为：缩短用户在数据库上执行某项操作花费的时间；或简单地表述为缩短数据库时间。 

其它时间模型统计信息会提供对特定操作（如登录操作、硬分析和软分析、PL/SQL 执行和 Java 执行）的量化影响（以时间为单位）。

时间模型统计信息的层次结构 

      本幻灯片列出了时间模型统计信息之间的关系。这些关系组成两个结构树：后台所用时间和数据库时间。结构树中的子项所报告的时间均包含在结构树中的相应父项内。 

      数据库时间：执行数据库用户级调用的所用时间量（微秒）。此时间不包括用于实例后台进程（如 PMON）的时间。数据库时间从实例启动时开始累计。因为数据库时间的计算方法是将所有非空闲用户会话的时间组合在一起，所以，数据库时间可能会超过从实例启动算起的实际已用时间。例如，已运行 30 分钟的实例可能有四个活动用户会话，累计的数据库时间大约为 120 分钟。 

      数据库 CPU：数据库用户级调用的 CPU 时间量（微秒）。 

      序列装入所用时间：从数据字典获取下一个序号的所用时间量。如果将序列缓存起来，则此时间是用于在高速缓存用尽时补充高速缓存的时间量。在高速缓存中能找到序号时，不会记入任何时间。对于非缓存序列，将为每个 NEXTVAL 调用记入一定时间。

时间模型示例 

      所示的示例来自 AWR 报表。Statspack 报表也提供时间模型信息。统计信息按照占数据库时间值的百分比排序，因此占用时间最多的区域及其子项排在列表的第一个。本例中“sql execute elapsed time（sql 执行所用时间）”排在顶部。“Parse time elapsed（分析所用时间）”紧随其后，而“hard parse elapsed time（硬分析所用时间）”为“parse time elapsed（分析所用时间）”的子项。您马上可以看到，硬分析占用了几乎所有分析时间，而分析时间占用了数据库时间的绝大部分。 

注：各个统计信息的数据库时间百分比总和大于 100%。尽管没有将“parse time elapsed（分析所用时间）”作为“sql execute elapsed time（sql 执行所用时间）”的子项，但两者重复计入了部分元素。 

案例分析：

1、建立AWR snapshot

15:50:10 SYS@ test1 >exec dbms_workload_repository.create_snapshot();

PL/SQL procedure successfully completed.

2、进行事务操作

2、建立AWR snapshot

15:52:31 SYS@ test1 >exec dbms_workload_repository.create_snapshot();

PL/SQL procedure successfully completed.

通过AWR Report分析如下：

可以看出系统存在大量的hard parse，占用了大量的cpu time

Top Wait Events

查看用户session占用的CPU TIME:

案例分析：

CPU使用信息统计：

1、发现那些SQL运行了大量的PARSE

select name, value from v$sysstat where name like 'parse count%';

4、查看每个Session的CPU利用情况： 

select ss.sid,se.command,ss.value CPU ,se.username,se.program  
      from v$sesstat ss, v$session se  where ss.statistic# in  
     (select statistic#  from v$statname  
     where name = 'CPU used by this session')  
     and se.sid=ss.sid  
     and ss.sid>6 order by CPU desc;

select s.sid, s.event, s.MACHINE,s.OSUSER,s.wait_time, w.seq#, q.sql_text  
from v$session_wait w, v$session s, v$process p, v$sqlarea q  
where s.paddr=p.addr and  s.sid=&p 
       and  s.sql_address=q.address;

select s.sid,w.wait_time,w.seconds_in_wait,w.state,w.wait_time_micro,w.time_remaining_micro,w.time_since_last_wait_micro,p.USERNAME,  status,server,schemaname,osuser,machine,p.terminal,p.program,logon_time,w.event,w.wait_class,tracefile,sql_text,last_active_time  
     from v$session_wait w, v$session s, v$process p, v$sqlarea q  
     where s.paddr=p.addr and  s.sid  in  
     ( select sid from  (  select ss.sid  
           from v$sesstat ss, v$session se  where ss.statistic# in  
              (  select statistic# from v$statname  
              where name = 'CPU used by this session' )  
              and se.sid=ss.sid and ss.sid>6 order by ss.value desc  )
              where rownum<11 )  and s.sql_address=q.address;