oracle 时间模型,学习猿地-oracle时间模型-优快云博客

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<

conn/assysdbadeclarecntnumber;

pnumber;begincnt:=dbms_random.value(1,1000000);

p:=dbms_random.value(1,1000000);while(1>0) loop

cnt:=mod(cnt*p,1000000);endloop;end;/EOF

###################################################

cat thread.sh

#!/bin/shfor((i=1;i<=16;i++))

do/home/oracle/testcpu.sh &done

分别16,32个线程进行压力测试：

thread cpu loadavg(1min) db time cpu time elapse time16 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个并发进程下：

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.1Elapsed:34.45(mins)

DB Time:518.97(mins)

Time ModelStatistics DB/Inst: xxx Snaps: 14551-14552

-> Total time in database user-calls (DB Time): 31138.3s-> Statisticsincluding the word "background" measure background process

time,and so do not contribute tothe DB time statistic-> Ordered by % or DB time desc, Statistic name

Statistic Name Time (s)% ofDB Time------------------------------------------ ------------------ ------------

sql execute elapsed time 31,137.4 100.0DB CPU31,068.7 99.8PL/SQL execution elapsed time 31,065.0 99.8parse time elapsed3.4 .0hard parse elapsed time3.3 .0hard parse (sharing criteria) elapsed time0.2 .0hard parse (bind mismatch) elapsed time0.1 .0DB time31,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.5Elapsed:30.16(mins)

DB Time:913.54(mins)

Time ModelStatistics DB/Inst: xxx Snaps: 14552-14554

-> Total time in database user-calls (DB Time): 54812.4s-> Statisticsincluding the word "background" measure background process

time,and so do not contribute tothe DB time statistic-> Ordered by % or DB time desc, Statistic name

Statistic Name Time (s)% ofDB Time------------------------------------------ ------------------ ------------

sql execute elapsed time 54,811.1 100.0PL/SQL execution elapsed time 54,776.6 99.9DB CPU28,013.8 51.1parse time elapsed2.8 .0hard parse elapsed time2.6 .0hard parse (sharing criteria) elapsed time2.5 .0hard parse (bind mismatch) elapsed time0.2 .0DB time54,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的执行情况。