Oracle在9i或者早期的版本，对于性能优化方面，主要采用命中率模型，后面的版本，也保留着命中率模型，
比如在awr报告中，Instance Efficiency Percentages (Target 100%)就有关于buffer cache，library cache等相关的命中率。
命中率在性能优化时主要体现在：
- 当命中率不高时，可以通过参数的调整，提高命中率，从而可以提高系统的处理能力
不过命中率的弊端也显而易见：
- 命中率无法看到系统的cpu和IO处理能力的分配。
- 当系统存在性能问题时,比如：应用并发设计问题，锁争用等问题时，命中率无法有效的反映到。
所以，oracle引入了时间模型的概念：
这里有几个概念：
- 响应时间=服务时间+等待时间
- 从数据库的角度等价于：数据库响应时间=cpu时间+等待时间。
- elapse time：指时空上的物理时间
- db time：db time反映系统整体的资源（cpu，IO）被oracle使用的百分比情况，以user call为视角
- cpu time：指cpu的使用的有效时间
Db time= DB CPU+Foreground NO-Idle wait time + DB CPU ON QUEUE
这里边：
- db cpu即数据库任务使用cpu的时间
- Foreground NO-Idle wait time：非空闲的等待（不包括backgroud进程）
- DB CPU ON QUEUE:这里代表的是ready to run，但没有获得cpu运行时间片的在队列中等待时间
下面对数据库进行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的执行情况。