statspackreport分析.docx

1、statspackreport分析(1)调整的先后次序1.Tunethedesign.-Applicationdesigners2.Tunetheapplication.-Applicationdevelopers3.Tunememory.4.TuneI/O.5.Tunecontention.6.Tunetheoperatingsystem.Statspack分析报告详解：statspack输出结果中必须查看的十项内容1、负载间档(Loadprofile)2、实例效率点击率(Instanceefficiencyhitratios)3、首要的5个等待事件(Top5waitevents)4、等待事

2、件(Waitevents)5、闩锁等待6、首要的SQL(Topsql)7、实例活动(Instanceactivity)8、文件I/O(FileI/O)9、内存分配(Memoryallocation)10、缓冲区等待(Bufferwaits1.报表头信息数据库实例相关信息，包括数据库名称、ID、版本号及主机等信息。STATSPACKreportforDBNameDBIdInstanceInstNumReleaseClusterHost-BLISSDB4196236801blissdb19.2.0.4.0NOBLISSSnapIdSnapTimeSessionsCurs/SessComment-B

3、eginSnap:423-6月-0517:43:32103.3EndSnap:523-6月-0518:01:32126.1Elapsed:18.00(mins)CacheSizes(end)BufferCache:24MStdBlockSize:8KSharedPoolSize:48MLogBuffer:512K2.负载间档该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分。LoadProfilePerSecondPerTransaction-Redosize:431,200.1618,627,847.04zLogicalreads:4,150.76179,312.72B

4、lockchanges:2,252.5297,309.00Physicalreads:23.931,033.56Physicalwrites:68.082,941.04Usercalls:0.9641.36Parses:1.1248.44Hardparses:0.041.92Sorts:0.7733.28Logons:0.000.20Executes:2.36102.12Transactions:0.02Redosize：每秒产生的重做日志大小(单位字节)，可标志数据变更频率,数据库任务的繁重与否。本例中平均每秒产生了430K左右的重做，每个事务品均产生了18M的重做。Logicalreads

5、：平次每秒产生的逻辑读，单位是block。blockchanges：每秒block变化数量，数据库事物带来改变的块数量。Physicalreads：平均每秒数据库从磁盘读取的block数。Logicalreads和Physicalreads比较：大约有0.55%的逻辑读导致了物理I/O，平均每个事务执行了大约18万个逻辑读，在这个例子中，有一些大的事务被执行，因此很高的读取数目是可以接受的。Physicalwrites：平均每秒数据库写磁盘的block数。Usercalls：每秒用户call次数。Parses和Hardparses：每秒大约1.12个解析，其中有4%为硬解析，系统每25秒分析一

6、些SQL，都还不错。对于优化好的系统，运行了好几天后，这一列应该达到0，所有的sql在一段时间后都应该在共享池中。Sorts：每秒产生的排序次数。Executes：每秒执行次数。Transactions：每秒产生的事务数，反映数据库任务繁重与否。%BlockschangedperRead:54.27RecursiveCall%:86.94Rollbackpertransaction%:12.00RowsperSort:32.59%BlockschangedperRead：说明46%的逻辑读是用于那些只读的而不是可修改的块，该系统只更新54%的块。Rollbackpertransaction%：

7、事务回滚的百分比。计算公式为：Round(Userrollbacks/(usercommits+userrollbacks),4)*100%。本例中每8.33个事务导致一个回滚。如果回滚率过高，可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来UndoBlock的竞争。3.实例命中率该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要。InstanceEfficiencyPercentages(Target100%)BufferNowait%:100.00RedoNoWait%:100.00BufferHit%:99.42In-memorySort%:100.00Library

8、Hit%:98.11SoftParse%:96.04ExecutetoParse%:52.57LatchHit%:100.00ParseCPUtoParseElapsd%:11.40%Non-ParseCPU:99.55BufferNowait%：在缓冲区中获取Buffer的未等待比率，BufferNowait99%说明，有可能是有热块(查找x$bh的tch和v$latch_children的cachebufferschains)。RedoNoWait%：在Redo缓冲区获取Buffer的未等待比率。BufferHit%：数据块在数据缓冲区中的命中率，通常应在90%以上，否则，小于95%，需要

9、调整重要的参数，小于90%可能是要加db_cache_size，但是大量的非选择的索引也会造成该值很高（大量的dbfilesequentialread）。如果一个经常访问的列上的索引被删除，可能会造成bufferhit显著下降。如果增加了索引，但是它影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致bufferhit显著增高。如果命中率变化幅度很大，说明需要改变SQL模式。In-memorySort%：在内存中的排序率。LibraryHit%：主要代表sql在共享区的命中率，通常在95%以上，否则需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。SoftPar

10、se%：近似看作sql在共享区的命中率，小于Executions，就可能出现该比率小于0的情况。本例中，对于每个分析来说大约执行了2.1次。该值99%，否则存在严重的性能问题，比如绑定等会影响该参数。ParseCPUtoParseElapsd%：计算公式为：ParseCPUtoParseElapsd%=100*(parsetimecpu/parsetimeelapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。此处为11.4%，非常低，用于解析花费的每个CPU秒花费了大约8.77秒的wallclock时间，这说明花了很多时间等待一个资源。如果该比率为100%，意味着C

11、PU时间等于经过的时间，没有任何等待。%Non-ParseCPU：计算公式为：%Non-ParseCPU=round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。4.SharedPool相关统计数据SharedPoolStatisticsBeginEnd-MemoryUsage%:60.4562.42%SQLwithexecutions1:81.3878.64%MemoryforSQLw/exec1:70.

12、3668.02MemoryUsage%：正在使用的共享池的百分率。这个数字应该长时间稳定在75%90%。如果这个百分率太低，就浪费内存。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。%SQLwithexecutions1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这

13、仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在18分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了-系统只是没有理由去执行它。%MemoryforSQLw/exec1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与%SQLwithexecutions1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%85%的共享池被使用。如果Statspack报表的时间窗口足够大

14、到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。5.首要等待事件常见等待事件说明：oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件。TIMED_STATISTICS：=TRUE，等待事件按等待的时间排序，=FALSE，等待事件按等待的数量排序。运行statspack期间必须session上设置TIMED_STATISTICS=TRUE。空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事

15、件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。Top5TimedEvents%TotalEventWaitsTime(s)ElaTime-dbfilesequentialread22,15425962.14CPUtime4911.67logfileparallelwrite2,439266.30dbfileparallelwrite400225.32SQL*Netmessagefromdblink4,575153.71-这里是比其他任何事件都能使速度减慢的事件。比较影响性能的常见等待事件：dbfilescatteredrea

16、d：该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj)。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描，而且表比较小，把该表存人keep池。如果是大表经常进行全表扫描，那么应该是OLAP系统，而不是OLTP的。dbfilesequentialread：该事件说明在单个数据块上大量等待，该值过高通常

17、是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整,DB_CACHE_SIZE可以决定该事件出现的频率。dbfilesequentialread：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来（如效率不高的sql），通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整，DB_CACHE_SIZE可以决定该事件出现的频率。bufferbu

18、sywait：当缓冲区以一种非共享方式或者如正在被读入到缓冲时，就会出现该等待。该值不应该大于1%，确认是不是由于热点块造成（如果是可以用反转索引，或者用更小块大小）。latchfree：常跟应用没有很好的应用绑定有关。闩锁是底层的队列机制（更加准确的名称应该是互斥机制），用于保护系统全局区（SGA）共享内存结构闩锁用于防止对内存结构的并行访问。如果闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题都与使用绑定变量失败（库缓存闩锁）、生成重作问题（重执行分配闩锁）、缓存的争用问题(缓存LRU链)以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。logbuffe

19、rspace：日志缓冲区写的速度快于LGWR写REDOFILE的速度，可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。logfileswitch：通常是因为归档速度不够快，需要增大重做日志。logfilesync：当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率,为减少这个等待事件，须一次提交更多记录，或者将重做日志REDOLOG文件访在不同的物理磁盘上。Waittime:等待时间包括日志缓冲的写入和发送操作。6.数

20、据库用户程序发生的所有等待事件WaitEventsforDB:BLISSDBInstance:blissdbSnaps:4-5-s-second-cs-centisecond-100thofasecond-ms-millisecond-1000thofasecond-us-microsecond-1000000thofasecond-orderedbywaittimedesc,waitsdesc(idleeventslast)AvgTotalWaitwaitWaitsEventWaitsTimeoutsTime(s)(ms)/txn-dbfilesequentialread22,1540259

21、12886.2logfileparallelwrite2,4392,012261197.6dbfileparallelwrite4000225516.0SQL*Netmessagefromdblink4,5750153183.0SQL*Netmoredatafromdblin64,49001302,579.6controlfileparallelwrite416051316.6dbfilescatteredread456051118.2writecompletewaits9055680.4controlfilesequentialread370051314.8logbufferspace126

22、04345.0freebufferwaits11133130.4logfileswitchcompletion13021880.5logfilesync900183.6logfilesequentialread1000160.4latchfree176080.7directpathread560012.2directpathwrite560012.2SQL*Netmoredatatoclient1730006.9SQL*Netmessagetodblink4,575000183.0LGWRwaitforredocopy80010.3logfilesinglewrite100010.4dbfil

23、esinglewrite50000.2SQL*Netbreak/resettoclien50000.2asyncdiskIO150000.6SQL*Netmessagefromclient78903,290417031.6virtualcircuitstatus36361,082300691.4wakeuptimemanager34341,034304031.4SQL*Netmessagetoclient79100031.6SQL*Netmoredatafromclien300001.2-7.数据库后台进程发生的等待事件BackgroundWaitEventsforDB:BLISSDBInst

24、ance:blissdbSnaps:4-5-orderedbywaittimedesc,waitsdesc(idleeventslast)AvgTotalWaitwaitWaitsEventWaitsTimeoutsTime(s)(ms)/txn-logfileparallelwrite2,4392,012261197.6dbfileparallelwrite4000225516.0controlfileparallelwrite406051316.2controlfilesequentialread258041610.3dbfilesequentialread1901510.8logbuff

25、erspace240091.0logfilesequentialread1000160.4latchfree146090.6dbfilescatteredread600140.2directpathread560012.2directpathwrite560012.2LGWRwaitforredocopy80010.3logfilesinglewrite100010.4rdbmsipcmessage7,3393,3373,172432293.6pmontimer3733731,083290314.9smontimer33924#0.1-8.TOPSQL调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询，将可对系统性能产生5%到5000%的增益。SQLorderedbyGetsforDB:BLISSDBInstance:blissdbSnaps