详细解读STATSPACK报告.docx
《详细解读STATSPACK报告.docx》由会员分享，可在线阅读，更多相关《详细解读STATSPACK报告.docx（49页珍藏版）》请在冰豆网上搜索。
详细解读STATSPACK报告
详细解读STATSPACK报告
说在前面，很容易被忽略的几个点：
在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。
尤其需要注意的就是时间段，脱离了时间段的statspck将是毫无意义的，甚至会得出错误的结果。
怎样读懂报告
查看统计报表，首先查看十项内容：
查看统计报表，首先查看十项内容：
１）首要的５个等待事件（TOP5WAITEVENTS）
２）负载简档（LOADPROFILE）
３）实例效率点击率（INSTANCEEFFICIENCYHITRATIOS）
４）等待事件（WAITEVENTS）
５）闩锁等待（LATCHWAITS）LatchActivity
６）首要的SQL（TOPSQL）sqlorderedbycpu
７）实例活动（INSTANCEACTIVITY）instanceactivity
８）文件I/O（FILEI/O）orderedbyios
９）内存分配（MEMORYALLOCATION）librarycacheactivity（SharedPoolAdvisory）
１０）缓冲区等待（BUFFERWAITS）bufferpooladvisory
cd/home/oracle
morestatspack.1st
１１）PGA统计信息（PGASTATS）pgaaggrtargetstatspgamemoryadvisory
1、报表头信息
/*报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息。
另外，重点还需要关注一下报告产生的时间跨度（在这里是14分钟），以及并发数（在这里是272）。
DBNameDBIdInstanceInstNumReleaseClusterHost
-------------------------------------------------------------------------
ORA921924035339ora92110.2.0.1.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
i.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（softsoftparse），softparse和hardparse三种数量的综合。
软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache,session的默认值为0，表明PGA不会缓存任何SQL语句，他们会被缓存在共享池（SharedPool）中,但是你的session必须在共享池中去查找他们,sessioncachedcursors可以省略掉去共享池中查找这一步，调整session_cursor_cache:
altersessionsetsession_cached_cursors=100。
在这里，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%。
select*fromv$sysstatwherenamein（'usercommits','userrollbacks'）获取提交与回滚数
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的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
等待事件
一般解决方法
SequentialRead
调整相关的索引和选择合适的驱动行源
ScatteredRead
表明出现很多全表扫描。
优化code，cache小表到内存中。
FreeBuffer
增大DB_CACHE_SIZE，增大checkpoint的频率，优化代码
BufferBusySegmentheader
增加freelist或者freelistgroups
BufferBusyDatablock
隔离热块；使用反转索引；使用更小的块；增大表的initrans
BufferBusyUndoheader
增加回滚段的数量或者大小
BufferBusyUndoblock
Commitmore；增加回滚段的数量或者大小
LatchFree
检查具体的等待latch类型，解决方法参考后面介绍
Enqueue–ST
使用本地管理的表空间或者增加预分配的盘区大小
Enqueue–HW
在HWM之上预先分配盘区
Enqueue–TX4
在表或者索引上增大initrans的值或者使用更小的块
LogBufferSpace
增大LOG_BUFFER，改善I/O
LogFileSwitch
增加或者增大日志文件
Logfilesync
减小提交的频率；使用更快的I/O；或者使用裸设备
Writecompletewaits
增加DBWR；提高CKPT的频率；
Top5TimedEvents
~~~~~~~~~~~~~~~~~~%Total
EventWaitsTime（s）ElaTime
---------------------------------------------------------------------------
CPUtime36154.14
logfilesync74,32410115.22
enqueue7298813.28
dbfilesequentialread7,303659.76
SQL*Netmessagefromdblink482203.05
WaitEventsforDB:
ORA92Instance:
ora92Snaps:
13-14
->s-second
->cs-centisecond-100thofasecond
->ms-millisecond-1000thofasecond
->us-microsecond-1000000thofasecond
->orderedbywaittimedesc,waitsdesc（idleeventslast）
Avg
TotalWaitwaitWaits
EventWaitsTimeoutsTime（s）（ms）/txn
--------------------------------------------------------------------------
logfilesync74,324010111.0
enqueue7290881210.0
dbfilesequentialread7,30306590.1
SQL*Netmessagefromdblink482020420.0
dbfileparallelwrite725014190.0
dbfilescatteredread2,4150630.0
processstartup8044400.0
latchfree1,3071,300210.0
logfileparallelwrite67,0420200.9
controlfilesequentialread2690130.0
single-taskmessage2401330.0
controlfileparallelwrite3250120.0
bufferbusywaits3,3680100.0
logfileswitchcompletion1900200.0
directpathread2880000.0
LGWRwaitforredocopy1,0320000.0
SQL*Netmoredatatoclient1,3900000.0
kksfbcchildcompletion110100.0
logfilesequentialread20050.0
directpathwrite1280000.0
librarycachepin140000.0
SQL*Netmoredatafromdblin40000.0
logfilesinglewrite20010.0
SQL*Netmessagetodblink4820000.0
bufferdeadlock3030000.0
SQL*Netmessagefromclient436,7730143,2213285.8
jobqslavewait2,6881,6646,68824880.0
wakeuptimemanager2727791292970.0
SQL*Netmessagetoclient436,7720005.8
BackgroundWaitEventsforDB:
ORA92Instance:
ora92Snaps:
13-14
->orderedbywaittimedesc,waitsdesc（idleeventslast）
Avg
TotalWaitwaitWaits
EventWaitsTimeoutsTime（s）（ms）/txn
--------------------------------------------------------------------------
dbfileparallelwrite725014190.0
logfileparallelwrite67,0440200.9
controlfilesequentialread1860140.0
controlfileparallelwrite3250120.0
dbfilescatteredread380070.0
directpathread2880000.0
LGWRwaitforredocopy1,0320000.0
dbfilesequentialread30060.0
logfilesequentialread20050.0
directpathwrite1280000.0
logfilesinglewrite20010.0
rdbmsipcmessage63,1671,0614,970790.8
smontimer33879######0.0
pmontimer29229282328190
升级会员 