~~~~~~~~~~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 executions>1: 36.31 36.10 --
% Memory for SQL w/exec>1: 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
|
