标签：des com class http blog div code img style java javascript
Oracle在9i或者早期的版本，对于性能优化方面，主要采用命中率模型，后面的版本，也保留着命中率模型，
比如在awr报告中，Instance
Efficiency Percentages (Target 100%)就有关于buffer cache，library cache等相关的命中率。
命中率在性能优化时主要体现在：
不过命中率的弊端也显而易见：
所以，oracle引入了时间模型的概念：
这里有几个概念：
Db time= DB CPU+Foreground NO-Idle wait time + DB CPU ON QUEUE
这里边：
下面对数据库进行cpu密集型的测试：
$ cat testcpu.sh #!/bin/sh . /home/oracle/.bash_profile sqlplus -S /nolog<<EOF conn /as sysdba declare cnt number; p number; begin cnt:=dbms_random.value(1,1000000); p:=dbms_random.value(1,1000000); while(1>0) loop cnt:=mod(cnt*p,1000000); end loop; end; / EOF ################################################### cat thread.sh #!/bin/sh for((i=1;i<=16;i++)) do /home/oracle/testcpu.sh & done
分别16,32个线程进行压力测试：
thread cpu loadavg(1min) db time cpu time elapse time 16 100% 16.08 31,138s 31,069s 34.45 (mins) 32 100% 31.81 54,812s 28,014s 30.16 (mins)
这里cpu被完全利用，cpu time大小为30*60*16=28,800s;(上面实验中取的awr时间在30分钟左右)
而db
time会随着线程数的增加有所增加，虽然可能没有获得cpu时间，但是在run queue队列上，也会计入db time。
下面看下具体的awr报告：
16个并发进程下： <pre class="brush: sql; title: ; notranslate" title=""> Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 14551 18-Apr-12 23:00:25 36 2.1 End Snap: 14552 18-Apr-12 23:34:51 20 2.1 Elapsed: 34.45 (mins) DB Time: 518.97 (mins) Time Model Statistics DB/Inst: xxx Snaps: 14551-14552 -> Total time in database user-calls (DB Time): 31138.3s -> Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic -> Ordered by % or DB time desc, Statistic name Statistic Name Time (s) % of DB Time ------------------------------------------ ------------------ ------------ sql execute elapsed time 31,137.4 100.0 DB CPU 31,068.7 99.8 PL/SQL execution elapsed time 31,065.0 99.8 parse time elapsed 3.4 .0 hard parse elapsed time 3.3 .0 hard parse (sharing criteria) elapsed time 0.2 .0 hard parse (bind mismatch) elapsed time 0.1 .0 DB time 31,138.3 N/A -------------------------------------------------------------
32个并发进程下： Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 14552 18-Apr-12 23:34:51 20 2.1 End Snap: 14554 19-Apr-12 00:05:01 52 2.5 Elapsed: 30.16 (mins) DB Time: 913.54 (mins) Time Model Statistics DB/Inst: xxx Snaps: 14552-14554 -> Total time in database user-calls (DB Time): 54812.4s -> Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic -> Ordered by % or DB time desc, Statistic name Statistic Name Time (s) % of DB Time ------------------------------------------ ------------------ ------------ sql execute elapsed time 54,811.1 100.0 PL/SQL execution elapsed time 54,776.6 99.9 DB CPU 28,013.8 51.1 parse time elapsed 2.8 .0 hard parse elapsed time 2.6 .0 hard parse (sharing criteria) elapsed time 2.5 .0 hard parse (bind mismatch) elapsed time 0.2 .0 DB time 54,812.4 N/A
了解了awr里的时间模型：那么接下来:
1，等待事件
oracle记录埋点的事件所花费的时间，不同的版本等待事件略有差异。
查询v$system_event来监控到oracle各种等待时间的时间，就可以诊断数据库的性能瓶颈了。
2，top
sql：
oracle在sql的执行监控中记录了八个时间：
APPLICATION_WAIT_TIME，CONCURRENCY_WAIT_TIME，CLUSTER_WAIT_TIME，USER_IO_WAIT_TIME，PLSQL_EXEC_TIME，JAVA_EXEC_TIME，CPU_TIME，ELAPSED_TIME。
oracle可以根据这些时间来监控sql的执行情况。
标签：des com class http blog div code img style java javascript
原文地址：http://www.cnblogs.com/xpchild/p/3694972.html
