Yftlyc详细解读 STATSPACK 报告.docx

Yftlyc详细解读 STATSPACK 报告.docx

《Yftlyc详细解读 STATSPACK 报告.docx》由会员分享，可在线阅读，更多相关《Yftlyc详细解读 STATSPACK 报告.docx（55页珍藏版）》请在冰豆网上搜索。

Yftlyc详细解读STATSPACK报告

生命是永恒不断的创造，因为在它内部蕴含着过剩的精力，它不断流溢，越出时间和空间的界限，它不停地追求，以形形色色的自我表现的形式表现出来。

－－泰戈尔

详细解读STATSPACK报告

说在前面，很容易被忽略的几个点：

在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。

尤其需要注意的就是时间段，脱离了时间段的statspck将是毫无意义的，甚至会得出错误的结果。

STATSPACKreportfor

1、报表头信息

/*报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息。

另外，重点还需要关注一下报告产生的时间跨度（在这里是14分钟），以及并发数（在这里是272）。

DBNameDBIdInstanceInstNumReleaseClusterHost

-------------------------------------------------------------------------

ORA921924035339ora9219.2.0.6.0NOjsdxh_db02

SnapIdSnapTimeSessionsCurs/SessComment

---------------------------------------------------------------

BeginSnap:

1314-Jul-0700:

18:

5227455,345.0

EndSnap:

1414-Jul-0700:

32:

5527255,823.8

Elapsed:

14.05（mins）

CacheSizes（end）

~~~~~~~~~~~~~~~~~

BufferCache:

5,120MStdBlockSize:

8K

SharedPoolSize:

400MLogBuffer:

2,048K

2、实例负载档信息

LoadProfile

~~~~~~~~~~~~PerSecondPerTransaction

------------------------------

Redosize:

422,086.464,706.23

Logicalreads:

23,200.54258.68

Blockchanges:

3,080.5934.35

Physicalreads:

31.460.35

Physicalwrites:

104.381.16

Usercalls:

409.324.56

Parses:

227.202.53

Hardparses:

7.220.08

Sorts:

213.872.38

Logons:

0.850.01

Executes:

1,191.3213.28

Transactions:

89.69

/*下面详细说明LoadProfile各项含义

Redosize:

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

Logicalreads:

平决每秒产生的逻辑读的block数。

LogicalReads=ConsistentGets+DBBlockGets

Blockchanges:

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

Physicalreads:

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

Physicalwrites:

平均每秒数据库写磁盘的block数。

Usercalls:

每秒用户调用次数。

Parses:

每秒解析次数，包括fastparse，softparse和hardparse三种数量的综合。

软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。

在这里，fastparse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；softparse是指在sharedpool中命中的情形；hardparse则是指都不命中的情况。

Hardparses:

每秒产生的硬解析次数,每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。

这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。

但该参数设置为similar时，存在bug，可能导致执行计划的不优。

Sorts:

每秒产生的排序次数。

Logons:

每秒登陆的次数。

Executes:

每秒执行次数。

Transactions:

每秒产生的事务数，反映数据库任务繁重与否。

%BlockschangedperRead:

13.28RecursiveCall%:

80.21

Rollbackpertransaction%:

0.03RowsperSort:

2.84

/*LoadProfile续

1）%BlockschangedperRead：

在每一次逻辑读中更改的块的百分比。

2）Rollbackpertransaction%:

看回滚率是不是很高，因为回滚很耗资源,如果回滚率过高,可能说明你的数据库经历了太多的无效操作,过多的回滚可能还会带来UndoBlock的竞争该参数计算公式如下:

Round（Userrollbacks/（usercommits+userrollbacks）,4）*100%。

3）RecursiveCall%:

递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。

4）RowsperSort:

平均每次排序操作的行数。

3、实例有效性信息

InstanceEfficiencyPercentages（Target100%）

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BufferNowait%:

99.98RedoNoWait%:

100.00

BufferHit%:

99.87In-memorySort%:

100.00

LibraryHit%:

99.67SoftParse%:

96.82

ExecutetoParse%:

80.93LatchHit%:

96.10

ParseCPUtoParseElapsd%:

6.93%Non-ParseCPU:

99.88

/*实例的有效性，这部分值越接近100越好，分项内容详细说明如下：

1）BufferNowait%：

在缓冲区中获取Buffer的未等待比率。

BufferNowait的这个值一般需要大于99%。

否则可能存在争用，可以在后面的等待事件中进一步确认。

2）RedoNoWait%：

在Redo缓冲区获取Buffer空间的未等待比率。

当redobuffer达到1M时，就需要写到redolog文件，所以一般当redobuffer设置超过1M，不太可能存在等待buffer空间分配的情况。

当前，一般设置为2M的redobuffer，对于内存总量来说，应该不是一个太大的值。

3）BufferHit%：

数据块在数据缓冲区中的命中率，通常应在95%以上。

否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。

一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的dbfilesequentialread），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。

命中率的突变，往往是一个不好的信息。

如果命中率突然增大，可以检查topbuffergetSQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查topphysicalreadsSQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。

4）In-memorySort%：

在内存中的排序率。

如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。

5）LibraryHit%：

STATEMENT在共享区的命中率，通常应该保持在95%以上，否则需要要考虑：

加大共享池；使用绑定变量；修改cursor_sharing等参数。

6）SoftParse%：

sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。

7）ExecutetoParse%：

一个语句执行和分析了多少次的度量。

计算公式为：

ExecutetoParse=100*（1-Parses/Executions）。

本例中，差不多每execution5次需要一次parse。

所以如果系统Parses>Executions，就可能出现该比率小于0的情况。

该值<0通常说明sharedpool设置或者语句效率存在问题，造成反复解析，reparse可能较严重,或者是可能同snapshot有关，通常说明数据库性能存在问题。

8）LatchHit%：

要确保>99%，否则存在严重的性能问题。

当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。

9）ParseCPUtoParseElapsd%：

计算公式为：

ParseCPUtoParseElapsd%=100*（parsetimecpu/parsetimeelapsed）。

即：

解析实际运行时间/（解析实际运行时间+解析中等待资源时间）。

如果该比率为100%，意味着CPU等待时间为0，没有任何等待。

10）%Non-ParseCPU：

计算公式为：

%Non-ParseCPU=round（100*1-PARSE_CPU/TOT_CPU）,2）。

如果这个值比较小，表示解析消耗的CPU时间过多。

与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。

SharedPoolStatisticsBeginEnd

------------

MemoryUsage%:

32.8733.12

%SQLwithexecutions>1:

80.0082.69

%MemoryforSQLw/exec>1:

77.6280.70

1）MemoryUsage%：

正在使用的共享池的百分率。

这个数字应该长时间稳定在75%～90%。

如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。

如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。

在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。

2）%SQLwithexecutions>1：

这是在共享池中有多少个执行次数大于一次的SQL语句的度量。

在一个趋向于循环运行的系统中，必须认真考虑这个数字。

在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。

在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。

只有系统连续运行相同的SQL语句组，这个数字才会接近100%。

这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。

剩下的20%的语句可能已经在那里了--系统只是没有去执行。

3）%MemoryforSQLw/exec>1：

这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。

这个数字将在总体上与%SQLwithexecutions>1非常接近，除非有某些查询任务消耗的内存没有规律。

在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。

如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。

这是一个受观察之间持续时间影响的统计数字。

可以期望它随观察之间的时间长度增大而增大。

小结：

通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，然而我们并不能由此来确定数据运行的性能。

当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。

我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。

而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。

接下来，开始查看wait事件。

4、TOP5及其他等待事件信息

/*oracle等待事件是衡量oracle运行状况的重要依据及指示，等待事件分为两类：

空闲等待事件和非空闲等待事件,TIMED_STATISTICS=TRUE那么等待事件按等待的时间排序，=FALSE那么事件按等待的数量排序。

运行statspack期间必须session上设置TIMED_STATISTICS=TRUE，否则统计的数据将失真。

空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。

对于常见的等待事件，说明如下：

1）dbfilescatteredread

该事件通常与全表扫描或者fastfullindexscan有关。

因为全表扫描是被放入内存中进行的进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散（scattered）读入BufferCache中。

该等待过大可能是缺少索引或者没有合适的索引（可以调整optimizer_index_cost_adj）。

这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。

当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。

因为全表扫描被置于LRU（LeastRecentlyUsed，最近最少适用）列表的冷端（coldend），对于频繁访问的较小的数据表，可以选择把他们Cache到内存中，以避免反复读取。

当这个等待事件比较显著时，可以结合v$session_longops动态性能视图来进行诊断，该视图中记录了长时间（运行时间超过6秒的）运行的事物，可能很多是全表扫描操作（不管怎样，这部分信息都是值得我们注意的）。

关于参数OPTIMIZER_INDEX_COST_ADJ＝n：

该参数是一个百分比值，缺省值为100，可以理解为FULLSCANCOST/INDEXSCANCOST。

当n%*INDEXSCANCOST

在具体设置的时候，我们可以根据具体的语句来调整该值。

如果我们希望某个statement使用索引，而实际它确走全表扫描，可以对比这两种情况的执行计划不同的COST，从而设置一个更合适的值。

2）dbfilesequentialread：

该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕（没有正确选择驱动行源），或者使用了非选择性索引。

通过将这种等待与statspack报表中已知其它问题联系起来（如效率不高的sql）,通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整。

3）bufferbusywait：

当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。

该值不应该大于1%。

当出现等待问题时，可以检查缓冲等待统计部分（或V$WAITSTAT），确定该等待发生在什么位置：

a）如果等待是否位于段头（SegmentHeader）。

这种情况表明段中的空闲列表（freelist）的块比较少。

可以考虑增加空闲列表（freelist，对于Oracle8iDMT）或者增加freelistgroups（在很多时候这个调整是立竿见影的（altertabletablenamestrorage（freelists2）），在8.1.6之前，这个freelists参数不能动态修改;在8.1.6及以后版本，动态修改feelists需要设置COMPATIBLE至少为8.1.6）。

也可以增加PCTUSED与PCTFREE之间距离（PCTUSED-to-pctfreegap），其实就是说降低PCTUSED的值，尽快使块返回freelist列表被重用。

如果支持自动段空间管理（ASSM），也可以使用ASSM模式，这是在ORALCE920以后的版本中新增的特性。

b）如果这一等待位于undoheader，可以通过增加回滚段（rollbacksegment）来解决缓冲区的问题。

c）如果等待位于undoblock上，我们需要增加提交的频率，使block可以尽快被重用；使用更大的回滚段；降低一致读所选择的表中数据的密度；增大DB_CACHE_SIZE。

d）如果等待处于datablock，表明出现了hotblock，可以考虑如下方法解决：

①将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布（可以增大pctfree值，扩大数据分布，减少竞争），以避开这个"热点"数据块。

②也可以减小数据块的大小，从而减少一个数据块中的数据行数，降低数据块的热度，减小竞争；③检查对这些热块操作的SQL语句，优化语句。

④增加hotblock上的initrans值。

但注意不要把initrans值设置的过于高了，通常设置为5就足够了。

因为增加事务意味着要增加ITL事务槽，而每个ITL事务槽将占用数据块中24个字节长度。

默认情况下，每个数据块或者索引块中是ITL槽是2个，在增加initrans的时候，可以考虑增大数据块所在的表的PCTFREE值，这样Oracle会利用PCTFREE部分的空间增加ITLslot数量，最大达到maxtrans指定。

e）如果等待处于indexblock，应该考虑重建索引、分割索引或使用反向键索引。

为了防止与数据块相关的缓冲忙等待，也可以使用较小的块，在这种情况下，单个块中的记录就较少，所以这个块就不是那么"繁忙"。

或者可以设置更大的PCTFREE,使数据扩大物理分布，减少记录间的热点竞争。

在执行DML（insert/update/delete）时，Oracle向数据块中写入信息，对于多事务并发访问的数据表，关于ITL的竞争和等待可能出现，为了减少这个等待，可以增加initrans，使用多个ITL槽。

在Oracle9i中，可以使用ASSM这个新特性Oracle使用位图来管理空间使用，减小争用。

4）latchfree：

当闩锁丢失率高于0.5%时，需要调整这个问题。

详细的我们在后面的LatchActivityforDB部分说明。

5）Enqueue队列是一种锁，保护一些共享资源，防止并发的DML操作。

队列采用FIFO策略，注意latch并不是采用的FIFO机制。

比较常见的有3种类型的队列：

ST队列，HW队列，TX4队列。

STEnqueue的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。

解决方法：

1）将字典管理的表空间改为本地管理模式2）预先分配分区或者将有问题的字典管理的表空间的nextextent设置大一些。

HWEnqueue是用于segment的HWM的。

当出现这种等待的时候，可以通过手工分配etents来解决。

TX4Enqueue等待是最常见的等待情况。

通常有3种情况会造成这种类型的等待：

1）唯一索引中的重复索引。

解决方法：

commit或者rollback以释放队列。

2）对同一个位图索引段（bitmapindexfragment）有多个update，因为一个bitmapindexfragment可能包含了多个rowid，所以当多个用户更新时，可能一个用户会锁定该段，从而造成等待。

解决方法同上。

3）有多个用户同时对一个数据块作update，当然这些DML操作可能是针对这个数据块的不同的行，如果此时没有空闲的ITL槽，就会产生一个block-level锁。

解决方法：

增大表的initrans值使创建更多的ITL槽；或者增大表的pctfree值，这样oracle可以根据需要在pctfree的空间创建更多的ITL槽；使用smallerblocksize，这样每个块中包含行就比较少，可以减小冲突发生的机会。

6）FreeBuffer：

这个等待事件表明系统正在等待内存中的可用空间，这说明当前Buffer中已经没有Free的内存空间。

如果应用设计良好，SQL书写规范，充分绑定变量，那这种等待可能说明BufferCache设置的偏小，你可能需要增大DB_CACHE_SIZE。

该等待也可能说明DBWR的写出速度不够，或者磁盘存在严重的竞争，可以需要考虑增加检查点、使用更多的DBWR进程，或者增加物理磁盘的数量,分散负载，平衡IO。

7）Logfilesinglewrite：

该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。

头块写单个进行，因为头块的部分信息是文件号，每个文件不同。

更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。

8）logfileparallelwrite：

从logbuffer写redo记录到redolog文件，主要指常规写操作（相对于logfilesync）。

如果你的Loggroup存在多个组成员，当flushlogbuffer时，写操作是并行的，这时候此等待事件可能出现。

尽管这个写操作并行处理，直到所有I/O操作完成该写操作才会完成（如果你的磁盘支持异步IO或者使用IOSLAVE，那么即使只有一个redologfilemember,也有可能出现此等待）。

这个参数和logfilesync时间相比较可以用来衡量logfile的写入成本。

通常称为同步成本率。

改善这个等待的方法是将redologs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redolog和data的数据文件位于不同的磁盘中。

9）logfilesync：

当一个用户提交或回滚数据时，LGWR将会话的redo记录从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。

在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率,为减少这个等待事件，须一次提交更多记录，或者将重做日志REDOLOG文件访在不同的物理磁盘上，提高I/O的性能。

10）logbufferspace：

日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。

11）logfileswitch：

通常是因为归档速度不够快。

表示所有的提交