statspack report分析(二)

Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间)
越高越好
% Non-Parse CPU:查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd %

如果一个经常访问的列上的索引被删除，可能会造成buffer hit 显著的下降
如果增加了索引，但是他影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显 著增高
如果你的命中率变化幅度很大，说明你要改变SQL模式

  Quote:

 
Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   33.79   57.02
    % SQL with executions>1:   62.62   73.24
  % Memory for SQL w/exec>1:   64.55   78.72

 

Shared Pool相关统计数据
Memory Usage %:共享池内存使用率，应该稳定在70%-90%间，太小浪费内存，太大则内存不足。
% SQL with executions>1:执行次数大于1的sql比率，若太小可能是没有使用bind variables。
% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:执行次数大于1的sql
消耗内存/所有sql消耗的内存

4、首要等待事件
常见等待事件说明:
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件,  TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序= FALSE那么事件按等待的数量排序.运行statspack期间必须session上设置TIMED_STATISTICS = TRUE.
空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，
非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。

比较影响性能常见等待事件
db file scattered read
    该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，
通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描,而且表比较小, 把该表存人keep池.如果是大表经常进行全表扫描,那么应该是olap系统,而不是oltp的.
db file sequential read
   该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整, DB_CACHE_SIZE可以决定该事件出现的频率
buffer busy wait
    当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待.该值不应该大于1%,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)
latch free
   常跟应用没有很好的应用绑定有关. 闩锁是底层的队列机制(更加准确的名称应该是互斥机制)，用于保护系统全局区(SGA)共享内存结构闩锁用于防止对内存结构的并行访问。如果闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题都与使用绑定变量失败(库缓存闩锁)、生成重作问题(重执行分配闩锁)、缓存的争用问题(缓存LRU链) 以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。
log buffer space
    日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。
logfile switch
    通常是因为归档速度不够快,需要增大重做日志
log file sync
    当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上。

Enqueue   最有可能是多个用户同时修改同一个块,如果没有空闲的ITL空间,就会出现数据库块级锁.

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