首页 > 开发 > 综合 > 正文

statspack报告数据结果解释

2024-07-21 02:07:20
字体:
来源:转载
供稿:网友

这篇文章来自于oracle中国用户组(www.oracle.com.cn)的文章,发现对自己学习性能调优很有帮助:

原文链接:http://www.cnoug.org/viewthread.php?tid=25353

statspack报告数据结果解释

本人将最近在学习性能调优时,所用笔记总结如下,欢迎批评指正
本文将不断更新,欢迎补充。(所列数据仅用于便于说明,没有实
际意义)

一、statspack 输出结果中必须查看的十项内容

1、负载间档(load profile)
2、实例效率点击率(instance efficiency hit ratios)
3、首要的5个等待事件(top 5 wait events)
4、等待事件(wait events)
5、闩锁等待
6、首要的sql(top sql)
7、实例活动(instance activity)
8、文件i/o(file i/o)
9、内存分配(memory allocation)
10、缓冲区等待(buffer waits)

二、输出结果解释

1、报表头信息
数据库实例相关信息,包括数据库名称、id、版本号及主机等信息


  quote:statspack report for

db name         db id    instance     inst num release     cluster host
------------ ----------- ------------ -------- ----------- ------- ------------
pormals       3874352951 pormals             1 9.2.0.4.0   no      njlt-server1

            snap id     snap time      sessions curs/sess comment
            ------- ------------------ -------- --------- -------------------
begin snap:     36  18-7月 -04 20:41:02      29      19.2

  end snap:     37  19-7月 -04 08:18:27      24      15.7

   elapsed:                              697.42 (mins)

cache sizes (end)
~~~~~~~~~~~~~~~~~
               buffer cache:       240m      std block size:        8k
           shared pool size:        96m          log buffer:      512k

2、负载间档
该部分提供每秒和每个事物的统计信息,是监控系统吞吐量和负载变化的重要部分


  quote:load profile
~~~~~~~~~~~~                            per second(秒)      per transaction事物
                                   ---------------       ---------------
                  redo size:                148.46              3,702.15
              logical reads:              1,267.94             31,619.12
              block changes:                  1.01                 25.31
             physical reads:                  4.04                100.66
            physical writes:                  4.04                100.71
                 user calls:                 13.95                347.77
                     parses:                  4.98                124.15
                hard parses:                  0.02                  0.54
                      sorts:                  1.33                 33.25
                     logons:                  0.00                  0.02
                   executes:                  2.46                 61.37
               transactions:                  0.04

  % blocks changed per read:    0.08    recursive call %:                30.38
rollback per transaction %:    0.42       rows per sort:               698.23

说明:
redo size:每秒产生的日志大小(单位字节),可标志数据库任务的繁重与否
logical reads:平决每秒产生的逻辑读,单位是block
block changes:每秒block变化数量,数据库事物带来改变的块数量
physical reads:平均每秒数据库从磁盘读取的block数
physical writes:平均每秒数据库写磁盘的block数
user calls:每秒用户call次数
parses:每秒解析次数,近似反应每秒语句的执行次数
       软解析每秒超过300次意味着你的"应用程序"效
       率不高,没有使用soft soft parse,调整session_cursor_cache
hard parses:每秒产生的硬解析次数
sorts:每秒产生的排序次数
executes:每秒执行次数
transactions:每秒产生的事务数,反映数据库任务繁重与否

3、实例命中率
该部分可以提前找出oracle潜在将要发生的性能问题,很重要


  quote:instance efficiency percentages (target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            buffer nowait %:  100.00       redo nowait %:              100.00
            buffer  hit   %:   99.96    in-memory sort %:               99.14
            library hit   %:   99.53        soft parse %:               99.57
         execute to parse %: -102.31         latch hit %:              100.00
parse cpu to parse elapsd %:   81.47     % non-parse cpu:               96.46

说明:
buffer nowait %:在缓冲区中获取buffer的未等待比率
redo nowait %:在redo缓冲区获取buffer的未等待比率
buffer  hit %:数据块在数据缓冲区中得命中率,通常应在90%以上,否则,需要调整
in-memory sort %:在内存中的排序率
library hit   %:主要代表sql在共享区的命中率,通常在95%以上,否,需要要考虑加
大共享池,绑定变量,修改cursor_sharing等参数。
soft parse %:近似看作sql在共享区的命中率,小于<95%,需要考虑到绑定,如果低于80%,
那么就可能sql基本没有被重用
execute to parse %:sql语句解析后被重复执行的次数,如果过低,可以考虑设置
session_cached_cursors参数
parse cpu to parse elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间)
越高越好
% non-parse cpu:查询实际运行时间/(查询实际运行时间+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 %:共享池内存使用率,应该稳定在75%-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运行状况的重要依据及指示,主要有空闲等待事件和非空闲等待事件
;空闲等待事件是oracle正等待某种工作,在诊断和优化数据库时候,不用过多注意这部分事件,
非空闲等待事件专门针对oracle的活动,指数据库任务或应用程序运行过程中发生的等待,这些等待事件是我们在调整数据库应该关注的。

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

最大的网站源码资源下载站,

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表