標簽: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