Oracle性能优化下的时间模型
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 |
|
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: |
|
% 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 |
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是指物理的流逝时间，这是一个采样的时间跨度基数。
原老弟，我来看看你。
I am so happy to read this. This is the kind of info that needs to be given and not the random misinformation that is at the other blogs. Appreciate your sharing this beneficial content.