~~~~~~~~~~Per Second Per Transaction
Redo size: 22,007.092,921.10
--很重要的参数，表示你数据变更频率
Logical reads:22,890.623,038.38
Block changes:95.8812.73
Physical reads: 5,413.37 718.54
Physical writes:5.67 0.75
User calls: 750.8599.66
Parses:183.20 24.32
----软解析每秒超过300次意味着你的"应用程序"效率不高，没有使用soft soft parse，调整session_cursor_cache
Hard parses:20.412.71
--每秒超过100次，就可能说明你绑定使用的不好
Sorts: 5.17 0.69
Logons:0.03 0.00
Executes: 185.1724.58
Transactions: 7.53
% Blocks changed per Read:0.42Recursive 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)
BufferHit %: 76.54In-memory Sort %:100.00
--BufferHit<95%,重要的参数,小于95%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）
Library Hit %: 97.07Soft 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 WaitsTime (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 2,91332.01
db file sequential read2,142,279 2,82030.99
db file scattered read 1,724,832 1,18313.00
buffer busy waits 198,6241,04211.44
log file sync 22,85791510.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: CRMTEMPInstance: crmtempSnaps: 3 -11
StatisticTotal per Secondper Trans
--------------------------------- ------------------ ----------
CPU used by this session291,318 98.1 13.0
CPU used when call started291,318 98.1 13.0
CR blocks created1,7840.6 0.1
Cached Commit SCN referenced 00.0 0.0
Commit SCN cached 00.0 0.0
DBWR buffers scanned 985,112331.6 44.0
DBWR checkpoint buffers written9480.30.0
DBWR checkpoints00.00.0
dirty buffers inspected 4830.20.0--脏缓冲的个数
free buffer inspected8,1542.70.4--假如数量很大,说明缓冲区过小
sorts (disk)00.00.0--不应当大于1-5%
sorts (memory)15,365 5.20.7
sorts (rows)1,445,018823.0109.2
summed dirty queue length24,667 8.31.1
