| DB Name |
DB Id |
Instance |
Inst num |
Release |
RAC |
Host |
| TEST1212 |
3399531915 |
test1212 |
1 |
10.2.0.1.0 |
NO |
DANDAN |
| Snap Id |
Snap Time |
Sessions |
Cursors/Session |
|
| Begin Snap: |
1 |
20-12月-10 21:01:03 |
15 |
2.5 |
| End Snap: |
2 |
20-12月-10 22:00:52 |
17 |
5.4 |
| Elapsed: |
59.81 (mins) |
|||
| DB Time: |
0.83 (mins) |
DBid是唯一的数据库的标示,在rman中也能看到该值
C:"Documents and Settings"sure>rman target /
恢复管理器: Release 10.2.0.1.0 - Production on 星期一 12月 20 22:34:01 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到目标数据库: TEST1212 (DBID=3399531915)
RMAN>
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。计算公式:
在59分钟里（其间收集了2次快照数据），数据库耗时0.83分钟，系统有1个CPU，平均CPU耗时0.83分钟，CPU利用率只有大约1.38%（0.83/59.81）。说明系统压力非常小(该系统啥都没做J)。
对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
Cache Sizes
| Begin |
End |
|||
| Buffer Cache: |
412M |
408M |
Std Block Size: |
8K |
| Shared Pool Size: |
156M |
160M |
Log Buffer: |
6,968K |
显示SGA中每个区域的大小,可用来与初始参数值比较。
shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析（或编译）后SQL、PL/SQL。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache,也就是尽可能的保持被命中(即传说中的命中率)。
Load Profile
| Per Second |
Per Transaction |
|||||
| Redo size: |
4,600.89 |
18,956.88 |
||||
| Logical reads: |
427.08 |
1,759.70 |
||||
| Block changes: |
29.02 |
119.57 |
||||
| Physical reads: |
1.84 |
7.57 |
||||
| Physical writes: |
0.37 |
1.52 |
||||
| User calls: |
0.11 |
0.47 |
||||
| Parses: |
5.13 |
21.14 |
||||
| Hard parses: |
0.59 |
2.44 |
||||
| Sorts: |
3.03 |
12.47 |
||||
| Logons: |
0.03 |
0.14 |
||||
| Executes: |
17.41 |
71.72 |
||||
| Transactions: |
0.24 |
|||||
| % Blocks changed per Read: |
6.80 |
Recursive Call %: |
99.93 |
|||
| Rollback per transaction %: |
0.00 |
Rows per Sort: |
189.64 |
|||
显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。
Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。
Logical reads：每秒/每事务逻辑读的块数
Block changes：每秒/每事务修改的块数
Physical reads：每秒/每事务物理读的块数
Physical writes：每秒/每事务物理写的块数
User calls：每秒/每事务用户call次数
Parses：SQL解析的次数
Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。
Sorts：每秒/每事务的排序次数
Logons：每秒/每事务登录的次数
Executes：每秒/每事务SQL执行次数
Transactions：每秒事务数
Blocks changed per Read：表示逻辑读用于修改数据块的比例
Recursive Call：递归调用占所有操作的比率
Rollback per transaction：每事务的回滚率
Rows per Sort：每次排序的行数
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
| Buffer Hit %: |
99.57 |
In-memory Sort %: |
100.00 |
| Library Hit %: |
92.37 |
Soft Parse %: |
88.46 |
| Execute to Parse %: |
70.52 |
Latch Hit %: |
99.99 |
| Parse CPU to Parse Elapsd %: |
84.03 |
% Non-Parse CPU: |
80.34 |
这一段包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。
Buffer Hit Ratio:也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
Buffer Nowait:表示在内存获得数据的未等待比例。
buffer hit:表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。
Redo NoWait:表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。
library hit:表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要调大shared pool区。
Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。
Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。
Non-Parse CPU:SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。
Execute to Parse:是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse:软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
Shared Pool Statistics
| Begin |
End |
|
| Memory Usage %: |
45.69 |
56.15 |
| % SQL with executions>1: |
52.03 |
32.99 |
| % Memory for SQL w/exec>1: |
87.15 |
60.31 |
Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。
SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。
Top 5 Timed Events
| Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
| CPU time |
37 |
74.1 |
|||
| db file sequential read |
3,312 |
12 |
4 |
24.1 |
User I/O |
| control file parallel write |
1,198 |
5 |
4 |
9.5 |
System I/O |
| os thread startup |
58 |
2 |
33 |
3.9 |
Concurrency |
| db file scattered read |
432 |
2 |
4 |
3.4 |
User I/O |