1、如果等待时间比服务时间长很多,那我们就要优化等待时间,如果服务时间比等待时间长很多，就要先优化服务时间
这就是owi思想
那我们就需要判断整个数据库系统平均响应时间中服务时间(Service time)和等待时间(Wait time)各占的百分比。
服务时间代表的是“ CPU used by this session”,是CPU服务会话所花费的所有时间。
Response Time = Service Time + Wait TIme(即响应时间=cpu服务时间+等待时间)
select a.value "Total CPU time" from v$sysstat a where a.name=‘CPU used by this session‘;
SQL> select a.value "Total CPU time" from v$sysstat a where a.name=‘CPU used by this session‘; Total CPU time -------------- 997592 Elapsed: 00:00:00.01 SQL>
2、会话级
(1)查看统计号 这里为2
select statistic# from v$statname where name=‘CPU used by this session‘；
SQL> select statistic# from v$statname where name=‘CPU used by this session‘； 2
(2)查v$sesstat
select sid,a.value "Total CPU time " from v$sesstat a where a.statistic#=2;
查看每一个会话的cpu时间
SQL> select sid,a.value "Total CPU time " from v$sesstat a where a.statistic#=2; SID Total CPU time ---------- --------------- 1 1 2 1 22 1 23 1 43 1 44 1 46 1 64 1 65 1 66 1 85 1 86 1 88 1 107 1 108 1 109 1 127 1 129 1 148 1 149 1 169 1 172 1 173 1 190 1 191 1 193 1 211 1 213 1 232 1 233 1 30 rows selected.
3、Service Time ＝ SQL解析时间 ＋ 递归调用时间 ＋ 其它时间
(1)SQL/PLSQL等解析时所花的时间，如果解析时间超过总的CPU服务时间20%，那么需要调优应用程序代码，比如绑定变量、SESSION_CURSOR_CACHE等
怎么样来查看SQL解析时间呢？分实例级和会话级
实例级：
select NAME,statistic# from v$statname where name like ‘%parse%‘;
SQL> select NAME,statistic# from v$statname where name like ‘%parse%‘; NAME STATISTIC# ---------------------------------------------------------------- ---------- parse time cpu 547 parse time elapsed 548 parse count (total) 549 parse count (hard) 550 parse count (failures) 551 parse count (describe) 552
select a.value "Total parse Cpu time" from v$sysstat a where a.name=‘parse time cpu‘;
统计号是548
SQL> select a.value "Total parse Cpu time" from v$sysstat a where a.name=‘parse time cpu‘; Total parse Cpu time -------------------- 64984 Elapsed: 00:00:00.00
会话级：
select sid,a.value "Total parse Cpu time" from v$sesstat a where a.statistic#=548;
SQL> select sid,a.value "Total parse Cpu time" from v$sesstat a where a.statistic#=548; SID Total parse Cpu time ---------- -------------------- 1 0 2 0 22 0 23 0 43 0 44 785 46 4 64 0 65 2 66 5 85 0 86 225 88 0 107 0 108 2 109 0 127 1 129 3 148 0 149 6 169 0 172 0 173 0 190 0 191 0 211 0 213 0 232 0 233 571 29 rows selected.
(2) 递归调用时间是用在：语义分析阶段查找数据字典或者PLSQL内部包造成的解析所花的CPU时间。就是内部字典的一些动作。
select name,statistic# from v$statname where name like ‘%cpu%‘;
SQL> select name,statistic# from v$statname where name like ‘%cpu%‘; NAME STATISTIC# ---------------------------------------------------------------- ---------- recursive cpu usage 9 parse time cpu 547
这里统计号为9
select a.value "Total recursive Cpu time" from v$sysstat a where a.name=‘recursive cpu usage‘;
SQL> select a.value "Total recursive Cpu time" from v$sysstat a where a.name=‘recursive cpu usage‘; Total recursive Cpu time ------------------------ 509888 Elapsed: 00:00:00.00
通过查找v$sysstat,v$sesstat,我们可以查看到递归调用的时间。
我们知道sga分类为library cache+rowcache
rowcache数据字典(data dictionary cache )
数据字典cache怎么优化？多半是一些不规范的参数导致, _row_cr 11g 隐含参数的问题
(3)一般来说。其他时间 ，在这里是花费最多的时间(多cpu 的 调度也在这里)
总的来说
select a.value "Total CPU",b.value "parse CPU",c.value "recursive CPU",a.value - b.value - c.value "Other"
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name=‘CPU used by this session‘
and b.name=‘parse time cpu‘
and c.name=‘recursive cpu usage‘;
SQL> select a.value "Total CPU",b.value "parse CPU",c.value "recursive CPU",a.value - b.value - c.value "Other" from v$sysstat a, v$sysstat b, v$sysstat c where a.name=‘CPU used by this session‘ and b.name=‘parse time cpu‘ 5 and c.name=‘recursive cpu usage‘; Total CPU parse CPU recursive CPU Other ---------- ---------- ------------- ---------- 998928 64995 509941 423992 Elapsed: 00:00:00.01
刚刚好： 998928 = 64995 + 509941 + 423992
(4)等待事件分两类: 非空闲 + 空闲等待事件(IDLE)
大部分空闲等待事件 都是客户端相关的消息传输事件
大量idel等待事件造成的性能问题，极有可能是应用服务器本身问题，或者网络问题,因为cpu 都空闲了。
查看下数据库的等待事件数据
select event,time_waited,average_wait from v$system_event
where event not in (
‘pmon time‘,
‘smon timer‘,
‘rdbms ipc message‘,
‘parallel dequeue wait‘,
‘virtual circuit‘,
‘SQL*Net message from client‘,
‘client message‘,
‘NULL event‘
)
order by time_waited desc;
结果如下：
EVENT TIME_WAITED AVERAGE_WAIT
---------------------------------------------------------------- ----------- ------------
DIAG idle wait 935522655 100.09
jobq slave wait 497321787 50.08
shared server idle wait 467876357 3000.92
Streams AQ: qmn coordinator idle wait 467875026 1400.44
Streams AQ: qmn slave idle wait 467873982 2737.96
dispatcher timer 467872026 6000.98
pmon timer 467819350 264.77
Space Manager: slave idle wait 467784915 499.1
Streams AQ: waiting for time management or cleanup tasks 464980103 1690836.74
VKRM Idle 169919651 3146660.21
os thread startup 290703 1.59
control file parallel write 126076 .08
log file parallel write 100734 .03
log file sync 61970 .08
db file async I/O submit 34403 .03
library cache lock 22077 959.85
PL/SQL lock timer 12407 98.47
control file sequential read 6042 0
ADR block file read 1845 .11
auto-sqltune: wait graph update 1500 250.02
Disk file operations I/O 1482 0
direct path sync 778 1.05
log file switch completion 537 .81
control file heartbeat 400 400
reliable message 392 .05
SQL*Net message to client 375 0
db file sequential read 364 .01
resmgr:internal state change 342 10.06
class slave wait 327 .01
asynch descriptor resize 326 0
switch logfile command 227 56.68
rdbms ipc reply 209 .06
enq: CR - block range reuse ckpt 134 .07
LGWR wait for redo copy 112 0
undo segment extension 110 .75
ADR block file write 91 .01
db file scattered read 85 .01
log file single write 55 .04
JS coord start wait 50 50.02
enq: PR - contention 36 1.17
db file single write 35 .02
enq: RO - fast object reuse 27 .01
latch: shared pool 25 .03
direct path write temp 24 .01
latch free 19 .15
Data file init write 15 .21
这是oracle性能调优的基础。