~~~~~~~~~~Per Second
Per Transaction
Redo size:
22,007.09
2,921.10
--很重要的参数，表示你数据变更频率
Logical reads:
22,890.62
3,038.38
Block changes:
95.88
12.73
Physical reads:
5,413.37
718.54
Physical writes:
5.67
0.75
User calls:
750.85
99.66
Parses:
183.20
24.32
----软解析每秒超过300次意味着你的"应用程序"效率不高，没有使用soft soft parse，调整session_cursor_cache
Hard parses:
20.41
2.71
--每秒超过100次，就可能说明你绑定使用的不好
Sorts:
5.17
0.69
Logons:
0.03
0.00
Executes:
185.17
24.58
Transactions:
7.53
% Blocks changed per Read:
0.42
Recursive Call %:
21.95
--如果有很多PLSQL，那么他就会比较高
Rollback per transaction %:
0.01
Rows per Sort:
159.13
--看回滚率是不是很高，因为回滚很耗资源
Instance Efficiency Percentages (Target 100%)
--这一部分通过可以提前找出ORACLE潜在将要发生的性能问题（所以很重要哦）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %:
99.71
Redo NoWait %:
100.00
--Buffer Nowait<99%说明，有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)
Buffer
Hit
%:
76.54
In-memory Sort %:
100.00
--Buffer
Hit<95%,重要的参数,小于95%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）
Library Hit
%:
97.07
Soft Parse %:
88.86
--Library Hit<95%,要考虑加大共享池，绑定变量，修改cursor_sharing等
Execute to Parse %:
1.06
Latch Hit %:
99.76
--Soft Parse<95%,需要考虑到绑定，如果低于80%，那么就可能sql基本没有被重用
Parse CPU to Parse Elapsd %:
89.28
% Non-Parse CPU:
91.37
--Latch Hit<99%,要确保99%，否则存在严重的性能问题，比如绑定等会影响该参数
如果一个经常访问的列上的索引被删除，可能会造成buffer hit 显著的下降如果增加了索引，但是他影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显著增高如果你的命中率变化幅度很大，说明你要改变SQL模式
Shared Pool Statistics
Begin
End
Memory Usage %:
89.18
85.56
--共享内存使用情况 70%-98%都在正常范围
% SQL with executions1:
36.31
36.10
--
% Memory for SQL w/exec1:
38.86
38.33
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~
% Total
Event
Waits
Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time
2,913
32.01
db file sequential read
2,142,279 2,820
30.99
db file scattered read
1,724,832 1,183
13.00
buffer busy waits
198,624
1,042
11.44
log file sync
22,857
915
10.06
TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序
= FALSE那么事件按等待的数量排序
常见事件
LOG FILE SYNC:
在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率
db file sequential read:
在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用非选择性的索引
DB_CACHE_SIZE:
可以决定该事件出现的频率
db file scattered read :
意味着等待于全表扫描有关系,通常全表扫描表数据放入内存中,但是被申请到的内存高速缓冲的每个区可能不连续,该值过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj)
,如果经常必须进行全表扫描,而且表比较小, 把该表存人keep池.如果是大表经常进行全表扫描,那么应该是olap系统,而不是oltp的
buffer busy wait:
当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待.该值不应该大于1%,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)
latch free:
常跟应用没有很好的应用绑定有关
Enqueue
:
最有可能是多个用户同时修改同一个块,如果没有空闲的ITL空间,就会出现数据库块级锁
logfile switch:
通常是因为归档速度不够快,需要增大重做日志
log buffer space:
日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小
TOP SQL
调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询,将可对系统性能产生5%到5000%的增益.
Instance Activity Stats for DB: CRMTEMP
Instance: crmtemp
Snaps: 3 -11
Statistic
Total
per Second
per Trans
--------------------------------- ------------------ ----------
CPU used by this session
291,318
98.1
13.0
CPU used when call started
291,318
98.1
13.0
CR blocks created
1,784
0.6
0.1
Cached Commit SCN referenced 0
0.0
0.0
Commit SCN cached
0
0.0
0.0
DBWR buffers scanned
985,112
331.6
44.0
DBWR checkpoint buffers written
948
0.3
0.0
DBWR checkpoints
0
0.0
0.0
dirty buffers inspected
483
0.2
0.0
--脏缓冲的个数
free buffer inspected
8,154
2.7
0.4
--如果数量很大,说明缓冲区过小
sorts (disk)
0
0.0
0.0
--不应当大于1-5%
sorts (memory)
15,365
5.2
0.7
sorts (rows)
1,445,018
823.0
109.2
summed dirty queue length
24,667
8.3
1.1
