statspack报告数据结果解释
来源：互联网 发布：易语言钓鱼源码 编辑：程序博客网 时间：2024/05/02 04:53
这篇文章来自于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: | |
|
2、负载间档
该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分
| Quote: | |
|
说明:
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: | |
|
说明:
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相关统计数据
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 文件
访在不同的物理磁盘上。
附加一部分内容:
调整statspack的收集门限
statspack有两种类型的收集选项：
级别（level）：控制收集数据的类型
门限（threshold）：设置收集的数据的阈值。
1．级别（level）
statspack共有三种快照级别，默认值是5
a.level 0: 一般性能统计。包括等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等等。
b.level 5: 增加SQL语句。除了包括level0的所有内容，还包括SQL语句的收集，收集结果记录在stats$sql_summary中。
c.level 10: 增加子锁存统计。包括level5的所有内容。并且还会将附加的子锁存存入stats$lathc_children中。在使用这个级别时需要慎重，建议在Oracle support的指导下进行。
可以通过statspack包修改缺省的级别设置
SQL>execute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);
通过这样的设置，以后的收集级别都将是0级。
如果你只是想本次改变收集级别，可以忽略i_modify_parameter参数。
SQL>execute statspack.snap(i_snap_level=>10);
2．快照门限
快照门限只应用于stats$sql_summary表中获取的SQL语句。
因为每一个快照都会收集很多数据，每一行都代表获取快照时数据库中的一个SQL语句，所以stats$sql_summary很快就会成为statspack中最大的表。
门限存储在stats$statspack_parameter表中。让我们了结一下各种门限：
a. executions_th 这是SQL语句执行的数量(默认值是100)
b. disk_reads_tn 这是SQL语句执行的磁盘读入数量（默认值是1000）
c. parse_calls_th 这是SQL语句执行的解析调用的数量（默认值是1000）
d. buffer_gets_th 这是SQL语句执行的缓冲区获取的数量（默认值是10000）
任何一个门限值超过以上参数就会产生一条记录。
通过调用statspack.modify_statspack_parameter函数我们可以改变门限的默认值。
例如：
SQL>execute statspack.modify_statspack_parameter(i_buffer_gets_th=>100000,i_disk_reads_th=>100000;
Instance Efficiency Percentages
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#每个事务执行次数
--45: 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 =
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#
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引起冲突;放置日志文件于高速磁盘上
write complete waits#>#0#用户等候buffer被写进文件，暗示着写回滚段的时候有着等待，需要调整回滚段，包括合理的回滚段数量和大小，回滚段位于高速磁盘。
附录：
Load Profile
~~~~~~~~~~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
- statspack报告数据结果解释
- ORACLE STATSPACK REPORT输出结果解释
- ORACLE STATSPACK REPORT输出结果解释
- ORACLE STATSPACK REPORT输出结果解释
- ORACLE STATSPACK REPORT输出结果解释
- statspack内容解释
- 如何读懂statspack报告
- 如何读懂statspack报告
- 自动生成statspack 报告
- 详细解读statspack报告
- statspack性能报告！
- 详细解读 STATSPACK 报告
- 详细解读 STATSPACK 报告
- oracle statspack 报告详解
- 详细解读 STATSPACK 报告
- 详细解读statspack报告
- 修改statspack 生成报告脚本
- Statspack分析报告详解(转)
- CppUnit测试框架入门(2)
- Hello World!
- 编程解决因误操作删除数据，进行数据恢复操作以后jpg,tif图像文件打不开的问题。
- RedFlag(红旗) Advanced Server4.1上安装Oracle 9.2.0并升级到9.2.0.4
- 一般要求下的页面打印
- statspack报告数据结果解释
- 利用 DataSetNavigator 在数据集上进行 XPath 查询
- 精通EJB（5） 为Beans增加功能
- test
- 简析JAVA的XML编程
- C#中数组的相关知识
- 总结了一下数据库连接池
- TStringGrid多选的复制与拷贝
- 微软软件实现技术授课系列内容之二:C++ Best Coding Practice
