Oracle Statspack报告中各项指标含义详解

今天在ITPUB看到介绍Statspack文章，还不错，现在转载下

转载之：http://www.itpub.net/thread-1368543-1-1.html

 

Oracle Statspack报告中各项指标含义详解

Data Buffer Hit Ratio#<#90#
数据块在数据缓冲区中的命中率，通常应该在90%以上，否则考虑加大 db_block_buffers(9i 以上可是db_cache_size)

Buffer Nowait Ratio#<#99#
在缓冲区中获取buffer 的未等待比率

Library Hit Ratio#<#98#

主要代表着sql在共享区的命中率，通常在98%以上

In Memory Sort Ratio#<#0#

如果过低说明有大量的排序在临时表空间中进行，可尝试增加sort_area_size

Redo Nowait Ratio#<#98#

写日志的不等待比率,太低可调整log_buffer(增加)和 _log_io_size(减小，默认为1/3*log_buffer/log_block_size,使得 _log_io_size 为合适的值，比如128k/log_block_size)

Soft Parse Ratio#<#90#


近似当作sql在共享区的命中率，通常高代表使用了绑定变量,太低需要调整应用使用绑定变量，或者参考cursor_sharing = force (9i 中增加了 similar )

Latch Hit Ratio#<#99#

内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考 _spin_count 参数设置

Percent Non-Parse CPU#<#95#
查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过长

Percent Parse CPU to Parse Elapsed#<#90#

解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好

Execute to Parse Percent#<#10#

该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设置
session_cached_cursors > 0

Memory Usage Percent#<#75#  

共享池的使用率，应该稳定在75%--90%之间，太小浪费内存，太大则显内存不足

Percent of SQLs with Execution>1#<#40#  

执行次数大于1的sql的比率（若太小可能是没有使用绑定变量）

Percent of Memory for SQl with Execution>1#<#0#

执行次数大于1的sql消耗内存/(所有sql消耗内存)

Instance Load Profile Redo Size/Sec#>#100000#  

每秒产生的日志大小（单位字节），可标志数据库任务的繁重与否

Redo Size/Tx#>#0#  

平均每个事务的日志生成量

Logical Reads/Sec(逻辑读)#>#0#

平均每秒产生的逻辑读,单位是block

Logical Reads/Tx#>#0#

平均每个事务产生的逻辑读,单位是block

Block Changes/Sec#>#100#  

每秒block变化数量，数据库事务带来改变的块数量

Block Changes/Tx#>#0#  

平均每个事务所导致的改变的块数

Physical Reads/Sec#>#100#  

平均每秒数据库从磁盘读取的block数

Physical Reads/Tx#>#0#  

平均每个事务从磁盘读取的block数

Physical Write/Sec#>#50#  

平均每秒写磁盘的block数

Physical Write/Tx#>#0#  

平均每个事务写磁盘的block数

User Calls/Sec#>#0#  

每秒用户call次数

User Calls/Tx#>#0#

每事务用户call次数

Parses/Sec#>#100#  

每秒解析次数，近似反应了每秒语句的执行次数

Parses/Tx#>#0#  

每事务产生的解析次数

Hard Parses/Sec#>#10#  

每秒产生的硬解析次数

Hard Parses/Tx#>#0#  

每事务产生的硬解析次数

Sorts/Sec#>#20#  

每秒产生的排序次数

Sorts/Tx#>#5#

每事务产生的排序次数

Transactions/Sec#>#0#  

每秒产生的事务数

Rows/Sort#>#0#

每次排序所涉及到的行数

Percent of Block Changed/Read#>#0#

发生变化的块数/读次数，变化的块需要从回滚段来数据

Recursive Call Percent#>#0#  

递归操作占所有操作的比率

Rollback/Tx Percent#>#5#  

事务回滚率（回滚开销很大）

Executes/Sec#>#0#

每秒执行次数

Execute/Tx#>#0#  

每个事务执行次数

Logons/Sec --46: Logons/Tx  

I/O Statistics(I/O统计数据) Table Space I/O#>#0#
表示各表空间在IO上的分布，若出现严重不均衡，则要重新考虑对象的存储规划和数据文件的磁盘规划


Datafile I/O#>#0#  

表示各数据文件的IO分布，若不均衡则需要重新考虑对象的存储规划

Table I/O（表I/O）#>#0#

对这些IO很大的表，要考虑放置在高速磁盘上，并且尽可能的分布在不同的磁盘上

TOP SQL Top SQL with High Buffer Gets#>#0#  

这类sql进行了大量的block的读，要检查该sql是否用到了索引，或者说表上是否存在合理的索引，对于必须全表扫描的大表可以考虑recycle buffer ,对于频繁进行全表扫描的小表可以考虑keep buffer，还有一种需要注意的情况就是如果通过索引获取数据比例占表数据比例过大，比如20%(举例数据)，就能导致buffer gets过大

Top SQL with High Physical Reads#>#0#

这类sql导致了大量的从磁盘获取数据，可能因为数据缓冲区太小，也可能是过多的全表扫描，需要考察索引是否合理，是否用到索引

Top SQL with High Execution Count#>#0#

这类sql是需要重点关注的，也许这些sql本身一次执行并没有消耗大量的时间或者空间，但由于频繁的执行对系统影响极大，所以只要有优化的可能到要对这些sql进行优化。还有另外一些情况，就是某些程序中可能大量频繁地使用dual表来获取一些信息(比如时间的计算等)，尽可能的使这类sql转化为应用本地能解决的函数，或者还存在一些由于设计上的缺陷导致不必要的查询，都要在设计的角度避免这些查询

Top SQL with High Shared Memory#>#0#  

这类sql使用了大量的内存，不一定执行的频繁，但是它可能把执行的频繁的sql涉及的一些数据挤出缓冲区，这同样将导致很多问题，所以也需要从尽可能的优化

Top SQL with High Version Count#>#20#  

表示多个用户的sql在字面上是一样的，或者sql虽然一样但是session的一些参数发生了改变（比如sort_area_size发生了变化）

Wait Events(等待事件) alter system set mts_dispatcher#>#0#  

当会话决定执行"ALTER SYSTEM SET MTS_DISPATCHERS = <string> "的时候等待DISPATCHERS的启动

BFILE check if exists#>#0#  

检查外部的bfile文件是否存在

BFILE check if open#>#0#  

检查外部的bfile文件是否已经open

BFILE closure#>#0#

等待关闭外部bfile文件

BFILE get length#>#0#

获得外部bfile文件的大小

BFILE get name object#>#0#

得到外部bfile文件的名字

BFILE get path object#>#0#  

得到外部bfile文件的路径

BFILE internal seek#>#0#  

BFILE open#>#0#
等待外部bfile被打开

BFILE read#>#0#  

等待外部bfile文件读取完毕

buffer busy due to global cache#>#0#  

buffer busy waits#>#0#

block正被读入缓冲区或者缓冲区正被其他session使用,出现此情况通常可能通过几种方式调整:增大data buffer,增加freelist，减小pctused,增加回滚段数目，增大initrans,考虑使用LMT

buffer deadlock#>#0#  

由于系统缓慢所产生而非应用产生了死锁

buffer latch#>#0#

会话等待'buffer hash chain latch'

buffer read retry#>#0#  

OPS下读buffer的过程中内容发生了变化于是重新读取

Cache simulator heap#>#0#  

checkpoint completed#>#0#
等待检查点的完成，通常出现这个问题的原因是IO问题严重，可调整跟检查点相关参数log_checkpoint_interval,log_checkpoint_timeout,db_block_max_dirty_target,fast_start_io_target 等，可间接的增大日志文件大小和增加日志文件组数

Contacting SCN server or SCN lock master#>#0#  

control file parallel write#>#0#  

等待写所有控制文件的完成，可将控制文件分散在不同的磁盘上

control file sequential read#>#0#  

读控制文件，在备份控制文件、OPS等情况下产生

control file single write#>#0#  

OPS下同一时刻只允许一个session将共享信息写入磁盘

conversion file read#>#0#  

db file parallel read#>#0#  

做恢复的并行从数据文件获取数据

db file parallel write#>#0#  

当多个IO可以同时发生时(多磁盘)，DBWR可并行写入，DBWR等待最后一个IO的完成

db file scattered read#>#0#  

一次获取的block被分散在buffer的不连续空间中，通常表示全表扫描过多，可检查应用程序是否合理的使用了索引，数据库是否合理的创建了索引

db file sequential read#>#0#  

通常暗示着通过索引获取数据量比较大（比如通过索引进行范围扫描获取表数据百分比过大），多表连接的时候连接顺序不当，hash join时hash_area_size无法容纳hash table

db file single write#>#0#  

更新数据文件头出现等待

debugger command#>#0#  

DFS db file lock#>#0#  

OPS下每个实例在数据文件上有一个共享的全局锁，当要offline数据文件的时候等候其他实例同步文件

DFS lock handle#>#0#

会话等待一个全局锁请求

direct path read#>#0#

通常发生在临时表空间排序、并行查询中

direct path read (lob) #>#0#

direct path write#>#0#  

direct方式导入数据(sqlldr,CTAS)、PDML、临时表空间排序

direct path write (lob)#>#0#  

dispatcher listen timer#>#0#  

dispatcher shutdown#>#0#  

dispatcher timer#>#0#  

DLM generic wait event#>#0#  

dupl. cluster key#>#0#  

enqueue#>#0#

对共享资源的获取要求一种排队(FIFO)的机制以保护共享资源，
ST enqueue表示空间分配或者释放导致的问题可采用LMT表空间来避免，
TX enqueue主要产生于唯一索引重复、bitmap index 的频繁更新、initrans太小或者pctfree过小

file identify#>#0#

file open#>#0#  

free buffer waits#>#0#  

在缓冲区中寻找可用buffer出现等待，可能数据缓冲区太小，也可能检查点间隔太长，也可能频繁的DML而IO成为瓶颈

free global transaction table entry#>#0#

分布式数据库中会话等待一个全局事务槽

free process state object#>#0#  

global cache bg acks#>#0#  

global cache cr request#>#0#  

global cache freelist wait#>#0#  

global cache lock busy#>#0#

会话等待将一个buffer从当前共享状态转换为当前独占状态

global cache lock cleanup#>#0#  

global cache lock null to s#>#0#  


global cache lock null to x#>#0#  

global cache lock open s#>#0#  

global cache lock open x#>#0#  

global cache lock s to x#>#0#  

global cache multiple locks#>#0#

global cache pending ast#>#0#  

global cache pending asts#>#0#  

global cache retry prepare#>#0#

global cache retry request#>#0#  

imm op#>#0#  

inactive session#>#0#  

inactive transaction branch#>#0#  

index block split#>#0#

当在索引中查找一个key的时候如果发现该索引block正在裂变则等待裂变完成

io done#>#0#

会话等待IO的完成

KSIM GDS request cancel#>#0#  

latch activity#>#0#  

latch free#>#0#  

latch是一种维护内存的锁，不采用排队机制，快速的获取然后很快释放，造成的原因通常有程序没有使用绑定变量、shared_pool_size设置过大（比如1G）、LRU竞争、某些块过热（访问太频繁）

LGWR wait for redo copy#>#0#

表示等待redo allocation and redo copy latches,可增加 _log_simulteneous_copies(默认为 2*CPUs)，但同时也容易引入redo allocation latch contention,所以需要慎重

library cache load lock#>#0#

library cache lock#>#0#  

library cache pin#>#0#  

listen endpoint status#>#0#  

LMON wait for LMD to inherit communication channels#>#0#

local write wait#>#0#  

lock manager wait for dlmd to shutdown#>#0#  

lock manager wait for remote message#>#0#  

log buffer space#>#0#

生成日志等待lgwr赶快写文件而腾出log buffer,可在init参数文件中增大 log_buffer,置日志文件于高速磁盘上

log file parallel write#>#0#  

当lgwr写日志文件的过程中出现等待，这个等待通常会导致 log file sync事件,放置日志文件于高速磁盘上

log file sequential read#>#0#  

log file single write#>#0#  

log file switch (archiving needed)#>#0#

当日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，可增大日志文件和增加日志组，调整log_archive_max_processes

log file switch (checkpoint incomplete)#>#0#

当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，通常是io有严重问题，可增大日志文件和增加日志组

log file switch (clearing log file)#>#0#  

log file switch completion#>#0#  

write complete waits#>#0#

用户等候buffer被写进文件，暗示着写数据文件等待

log file sync#>#0#

当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长（可能是因为一次log io size 太大），可调整 _log_io_size，结合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突;置日志文件于高速磁盘上

log file sync
： 当某个因素导致需要写 redo 进 file的时候（通常是commit发生），发现 lgwr 正在写，而产生等待 造成的因素： 1： commit 太频繁（这个道理的解释可以说比如我们去食堂带饭，一次带一盒跟一次带2合），虽然2合可能多消耗一点力气，但这个来回的准备动作可以看做进程之间的通信、磁头的控制权的获取等等硬件因素，所以不是简单的1次写100k等于50k写2次,一次写100的代价会小于2次写50k，但问题在于如果有在刚开始写之后有其他commit发生，该commit可能在第一次50k写完之后就开始写入，这样只等待50k的时间而不用等待100k的写时间。这是很微小的发生在commit不频繁但是大事务经常存在的时候的现象。这个时候调整_log_io_size 或许能产生效果 2： 但若一次写的太多也可能导致该等待事件的出现3： 从IO本身的快慢来讲，更容易造成该事件，所以我们在IO方面来考虑更直接有效