author:skate
time:2010-03-25
如何查看awr/statspack报表，来定位系统的问题
数据库的性能指标一般都有什么？只有定好指标才能判定系统的性能，性能参考指标一般有如下几个：
1．响应时间：平均每事务的响应时间和，系统的响应速度
2. cpu时间：平均每事务所消耗的cpu时间（和响应时间不同，因为这里不报错cpu等待时间）
3. 等待时间：等待事件的平均每次等待时间
4. 逻辑读：就是一致读
5. 物理读：从disk读
6. 事务数/秒：平均每秒的事务数
7. redo size/秒:每秒产生的redo
8. redo size/事务：每事务产生的redo
9. 系统cpu(user%+sys%):系统cpu使用百分比
10. 系统内存使用率
11. 磁盘系统使用率
从awr/statspack报表判断系统性能，一般主要看事务响应时间和等待时间，来判断数据库是否正常为外界应用提供服务.
一般oltp系统的响应时间在15s内都是可以接受的。
Awr：
| DB Name |
DB Id |
Instance |
Inst num |
Release |
RAC |
Host |
| DBTICA |
4056410298 |
Orcl |
1 |
10.2.0.1.0 |
NO |
db3 |
| |
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
| Begin Snap: |
8190 |
13-Mar-10 21:00:46 |
69 |
4.3 |
| End Snap: |
8192 |
13-Mar-10 23:00:50 |
61 |
4.5 |
| Elapsed: |
|
120.07 (mins) |
|
|
| DB Time: |
|
30.40 (mins) |
|
|
Report Summary
Cache Sizes
| |
Begin |
End |
|
|
| Buffer Cache: |
19,872M |
19,872M |
Std Block Size: |
8K |
| Shared Pool Size: |
2,608M |
2,608M |
Log Buffer: |
14,360K |
Load Profile
| |
Per Second |
Per Transaction |
| Redo size: |
65,916.00 |
7,091.88 |
| Logical reads: |
35,000.51 |
3,765.69 |
| Block changes: |
444.38 |
47.81 |
| Physical reads: |
0.02 |
0.00 |
| Physical writes: |
12.19 |
1.31 |
| User calls: |
2,323.80 |
250.02 |
| Parses: |
593.14 |
63.82 |
| Hard parses: |
1.20 |
0.13 |
| Sorts: |
559.07 |
60.15 |
| Logons: |
0.05 |
0.01 |
| Executes: |
1,224.35 |
131.73 |
| Transactions: |
9.29 |
|
| % Blocks changed per Read: |
1.27 |
Recursive Call %: |
50.27 |
| Rollback per transaction %: |
0.02 |
Rows per Sort: |
0.13 |
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
| Buffer Hit %: |
100.00 |
In-memory Sort %: |
100.00 |
| Library Hit %: |
99.93 |
Soft Parse %: |
99.80 |
| Execute to Parse %: |
51.55 |
Latch Hit %: |
99.99 |
| Parse CPU to Parse Elapsd %: |
71.22 |
% Non-Parse CPU: |
94.67 |
Shared Pool Statistics
| |
Begin |
End |
| Memory Usage %: |
82.93 |
89.01 |
| % SQL with executions>1: |
89.78 |
83.82 |
| % Memory for SQL w/exec>1: |
80.34 |
75.70 |
Top 5 Timed Events
| Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
| CPU time |
|
1,418 |
|
77.7 |
|
| enq: TX - contention |
144 |
320 |
2,221 |
17.5 |
Other |
| log file sync |
29,576 |
18 |
1 |
1.0 |
Commit |
| latch: shared pool |
254 |
16 |
64 |
.9 |
Concurrency |
| log file parallel write |
74,540 |
12 |
0 |
.7 |
System I/O |
名词解释：db time， cpu time， elapsed time
db time
db time是指oracle花费在cpu上和等待事件上的时间,所以说，db_time=cpu_time+waited time。db time已经做为10g awr的一个采样指标，在上面的awr中可以看到，在9iR2上，我们同样可以通过top 5部分计算出来。在本例中，db time=1,418【CPU time】/77.7【%】/60=30.41min（和数据库监控值差一点啊）。这与awr db time一栏的采样数值基本是一致的.其实用任何等待事件都可以计算的
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方面是否存在瓶颈.
elapsed time
elapsed time是指物理的流逝时间，这是一个采样的时间跨度基数
下面几个需要计算的性能指标，其他的可以直接在awr/statspack查到
1. response time
基于transaction或者user call的平均响应时间，可以看做是我们做性能优化效果的一个证据.个人觉得没必要太注重这个数值。response time=service time(cpu time) + waited time。放到我们前面的这个awr中，平均事务响应时间也就可以近似这样计算：avg trans response time =1,418【CPU time】/77.7【%】/60/120.07【Elapsed】/9.29【transactions per second】=0.027s
2. 等待时间：
查看最多的等待事件的平均每次等待事件，在awr中直接就给计算出来了啊，在Top 5 Timed Events 中的avg wait(ms)就表示平均每次等待事件，在statspack就要自己计算了, avg time per wait=320【enq: TX - contention】/144=2.222s=2221ms（大约等于）
3. cpu时间
平均每事务的消耗cpu时间，在10g中可以直接查询到。但在9i中就需要计算
cpu time per trans =1418【cpu time】/9.29【transactions per second】/120.07【Elapsed】/60=0.021s
----end-----
