oracle在10g版本明确引入time model,直覺的作為一種量度名額反映給使用者。時間作為一種性能上的量度和反映,一直貫穿在oracle的各個版本中,可以說時間模型并不是10g特有的東西。隻不過,這種模型和概念在10g之前并沒有明确和加以細化,而且,在oracle各個版本的更新和演化中,也在不斷進行調整。
時間作為我們性能優化的一個重要參考,雖然有時候并不能給診斷帶來直接的切入點,比如我們常常提到的cpu time、db time甚至是response time,這些名額孤立起來因為負載和系統環境的不同可能并沒有橫向比較的意義,卻可以作為某個系統的狀态資料和優化前後的成果參考,有很高的縱比意義。
結合awr/statspack,看一下資料庫層面上對優化有指導意義的幾個重要的時間概念。
以下是一個10g版本的awk采樣片段:
DB Name | DB Id | Instance | Inst num | Release | RAC | Host |
ODSDB | 487655850 | ODSDB | 1 | 10.2.0.3.0 | NO | ODSDB |
Snap Id | Snap Time | Sessions | Cursors/Session | |
Begin Snap: | 13248 | 03-Jul-09 03:00:58 | 160 | 3.6 |
End Snap: | 13249 | 03-Jul-09 04:00:15 | 182 | 3.6 |
Elapsed: | 59.28 (mins) | |||
DB Time: | 513.50 (mins) |
Report Summary
Cache Sizes
Begin | End | |||
Buffer Cache: | 9,488M | 9,488M | Std Block Size: | 32K |
Shared Pool Size: | 368M | 368M | Log Buffer: | 14,356K |
Load Profile
Per Second | Per Transaction | |
Redo size: | 7,145,508.24 | 3,102,517.40 |
Logical reads: | 23,515.06 | 10,210.03 |
Block changes: | 11,143.67 | 4,838.48 |
Physical reads: | 1,385.75 | 601.68 |
Physical writes: | 761.58 | 330.67 |
User calls: | 278.86 | 121.08 |
Parses: | 127.85 | 55.51 |
Hard parses: | 2.76 | 1.20 |
Sorts: | 16.79 | 7.29 |
Logons: | 0.78 | 0.34 |
Executes: | 258.80 | 112.37 |
Transactions: | 2.30 |
% Blocks changed per Read: | 47.39 | Recursive Call %: | 86.38 |
Rollback per transaction %: | 5.52 | Rows per Sort: | 905.77 |
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | 99.93 | Redo NoWait %: | 99.97 |
Buffer Hit %: | 94.79 | In-memory Sort %: | 100.00 |
Library Hit %: | 97.14 | Soft Parse %: | 97.84 |
Execute to Parse %: | 50.60 | Latch Hit %: | 99.77 |
Parse CPU to Parse Elapsd %: | 65.49 | % Non-Parse CPU: | 98.44 |
Shared Pool Statistics
Begin | End | |
Memory Usage %: | 62.79 | 59.10 |
% SQL with executions>1: | 76.21 | 80.59 |
% Memory for SQL w/exec>1: | 73.92 | 81.61 |
Top 5 Timed Events
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
db file sequential read | 1,485,021 | 15,958 | 11 | 51.8 | User I/O |
CPU time | 7,157 | 23.2 | |||
db file scattered read | 175,351 | 3,423 | 20 | 11.1 | User I/O |
db file parallel read | 20,612 | 1,505 | 73 | 4.9 | User I/O |
Log archive I/O | 27,111 | 1,116 | 41 | 3.6 | System I/O |
1.cpu time
Oracle引入CPU time是在9iR2版本,cpu time是衡量一個資料庫負載的重要名額,可以将它看成是“CPU used by this session”的收集彙總。
9iR2之前,top 5部分稱之為“Top 5 Wait Events”,其中cpu time并不包含在top 5内,該部分是純粹的等待事件的彙總。而在9iR2之後,Top 5稱之為“top 5 timed events”,從字面上也可以發現二者的差別。oracle将cpu time作為一個事件納入top 5中,新的top 5包含cpu time和waited time 2部分,也就是db time。
我們可以通過cpu time與waited time的比值,來了解庫的負載和運作情況,通常較高的比例代表較好的性能;而通過平均每顆CPU耗費的cpu time和Elapsed time的比例,可以評估整個系統在CPU方面是否存在瓶頸.
2.db time
db time是指oracle花費在cpu上和等待事件上的時間,上面已經說過,db_time=cpu_time+waited time。
db time已經做為10g awr的一個采樣名額,在9iR2上,我們同樣可以通過top 5部分計算出來。在本例中,
db time=15958【db file sequential read】/51.8【%】/60=513.5min。這與awr db time一欄的采樣數值是一緻的.
3.response time
基于transaction或者user call的平均響應時間,可以看做是我們做性能優化效果的一個傳遞和對比。
response time=service time(cpu time) + waited time。放到我們前面的這個awr中,平均事務響應時間也就可以近似這樣計算:
avg trans response time =15958【db file sequential read】/51.8【%】/60/59.28【Elapsed】/2.30【transactions per second】=3.77s
對于9iR2之前,需要通過”CPU used by this session“來計算cpu時間,通過“Top 5 Wait Events”計算等待事件時間,同樣可以得出DB time和response time.
4.elapsed time
elapsed time是指實體的流逝時間,這是一個采樣的時間跨度基數。