1-5 Top 5 Timed EventsWaits : 该等待事件发生的次数， 对于DB CPU此项不可用Times : 该等待事件消耗的总计时间，单位为秒， 对于DB CPU 而言是前台进程所消耗CPU时间片的总和，但不包括Wait on CPU QUEUEAvg Wait(ms) : 该等待事件平均等待的时间， 实际就是 Times/Waits，单位ms， 对于DB CPU此项不可用% Total Call Time: 该等待事件占总的call time的比率total call time = total CPU time + total wait time for non-idle events% Total Call Time = time for each timed event / total call timeWait Class: 等待类型Concurrency,System I/O,User I/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit2-1 Time Model StatisticsTime Model Statistics几个特别有用的时间指标：parse time elapsed、hard parse elapsed time 结合起来看解析是否是主要矛盾，若是则重点是软解析还是硬解析sequence load elapsed time sequence序列争用是否是问题焦点PL/SQL compilation elapsed time PL/SQL对象编译的耗时注意PL/SQL execution elapsed time 纯耗费在PL/SQL解释器上的时间。不包括花在执行和解析其包含SQL上的时间connection management call elapsed time 建立数据库session连接和断开的耗时failed parse elapsed time 解析失败，例如由于ORA-4031hard parse (sharing criteria) elapsed time 由于无法共享游标造成的硬解析hard parse (bind mismatch) elapsed time 由于bind type or bind size 不一致造成的硬解析 2-2 Foreground Wait ClassWait Class: 等待事件的类型，如上查询所示，被分作12个类型。 10.2.0.5有916个等待事件，其中Other类型占622个。Waits: 该类型所属等待事件在快照时间内的等待次数%Time Out 等待超时的比率， 未 超时次数/waits * 100 (%)Total Wait Time: 该类型所属等待事件总的耗时，单位为秒Avg Wait(ms) : 该类型所属等待事件的平均单次等待时间，单位为ms ，实际这个指标对commit 和 user i/o 以及system i/o类型有点意义，其他等待类型由于等待事件差异较大所以看平均值的意义较小waits / txn: 该类型所属等待事件的等待次数和事务比2-3 前台等待事件Foreground Wait Events 前台等待事件，数据主要来源于DBA_HIST_SYSTEM_EVENTEvent 等待事件名字Waits 该等待事件在快照时间内等待的次数%Timeouts : 每一个等待事件有其超时的设置，例如buffer busy waits 一般为3秒， Write Complete Waits的 timeout为1秒，如果等待事件 单次等待达到timeout的时间，则会进入下一次该等待事件Total Wait Time 该等待事件 总的消耗的时间 ，单位为秒Avg wait(ms): 该等待事件的单次平均等待时间，单位为毫秒Waits/Txn: 该等待事件的等待次数和事务比2-4 后台等待事件Background Wait Events 后台等待事件， 数据主要来源于DBA_HIST_BG_EVENT_SUMMARY Event 等待事件名字Waits 该等待事件在快照时间内等待的次数%Timeouts : 每一个等待事件有其超时的设置，例如buffer busy waits 一般为3秒， Write Complete Waits的 timeout为1秒，如果等待事件 单次等待达到timeout的时间，则会进入下一次该等待事件Total Wait Time 该等待事件 总的消耗的时间 ，单位为秒Avg wait(ms): 该等待事件的单次平均等待时间，单位为毫秒Waits/Txn: 该等待事件的等待次数和事务比2-5 Operating System StatisticsNUM_CPU_SOCKETS 物理CPU的数目 NUM_CPU_CORES CPU的核数 NUM_CPUS 逻辑CPU的数目 SYS_TIME 在内核态被消耗掉的CPU时间片，单位为百分之一秒 USER_TIME 在用户态被消耗掉的CPU时间片，单位为百分之一秒 BUSY_TIME Busy_Time=SYS_TIME+USER_TIME 消耗的CPU时间片，单位为百分之一秒 AVG_BUSY_TIME AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS IDLE_TIME 空闲的CPU时间片，单位为百分之一秒 所有CPU所能提供总的时间片 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT OS_CPU_WAIT_TIME 进程等OS调度的时间，cpu queuing VM_IN_BYTES 换入页的字节数 VM_OUT_BYTES 换出页的字节数，部分版本下并不准确，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，仅供参考 IOWAIT_TIME 所有CPU花费在等待I/O完成上的时间 单位为百分之一秒 RSRC_MGR_CPU_WAIT_TIME 是指当resource manager控制CPU调度时，需要控制对应进程暂时不使用CPU而进程到内部运行队列中，以保证该进程对应的consumer group(消费组)没有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在内部运行队列上的时间，在等待时不消耗CPU 2-6 Service Statistcs按照Service Name来分组时间模型和 物理、逻辑读取， 部分数据来源于 WRH$_SERVICE_NAME;Service Name 对应的服务名 (v$services)， SYS$BACKGROUND代表后台进程， SYS$USERS一般是系统用户登录DB TIME (s): 本服务名所消耗的DB TIME时间，单位为秒DB CPU(s): 本服务名所消耗的DB CPU 时间，单位为秒Physical Reads : 本服务名所消耗的物理读Logical Reads : 本服务所消耗的逻辑读2-7 Service Wait Class Stats User I/O Total Wts : 对应该服务名下 用户I/O类等待的总的次数User I/O Wt Time : 对应该服务名下 用户I/O累等待的总时间，单位为 1/100秒Concurcy Total Wts: 对应该服务名下 Concurrency 类型等待的总次数Concurcy Wt Time :对应该服务名下 Concurrency 类型等待的总时间， 单位为 1/100秒Admin Total Wts: 对应该服务名下Admin 类等待的总次数Admin Wt Time: 对应该服务名下Admin类等待的总时间，单位为 1/100秒Network Total Wts : 对应服务名下Network类等待的总次数Network Wt Time： 对应服务名下Network类等待的总事件， 单位为 1/100秒2-8 Host CPULoad Average begin/end值代表每个CPU的大致运行队列大小。上例中快照开始到结束，平均 CPU负载增加了；与《2-5 Operating System Statistics》中的LOAD相呼应。%User+%System=> 总的CPU使用率，在这里是31.8%Elapsed Time * NUM_CPUS * CPU utilization= 60.23 (mins) * 24 * 31.8% = 459.67536 mins=Busy Time2-9 Instance CPU%Total CPU,该实例所使用的CPU占总CPU的比例 % of total CPU for Instance%Busy CPU，该实例所使用的Cpu占总的被使用CPU的比例 % of busy CPU for Instance例如共4个逻辑CPU，其中3个被完全使用，3个中的1个完全被该实例使用，则%Total CPU= ? =25%，而%Busy CPU= 1/3= 33%当CPU高时一般看%Busy CPU可以确定CPU到底是否是本实例消耗的，还是主机上其他程序% of busy CPU for Instance= （DB CPU+ background cpu time) / (BUSY_TIME /100)= (20,649.1 + 1,980.9)/ (2,894,855 /100)= 78.17%% of Total CPU for Instance = ( DB CPU+ background cpu time)/( BUSY_TIME+IDLE_TIME/100) = (20,649.1 + 1,980.9)/ ((2,894,855+5,568,240) /100) = 26.73%
