RAC数据库集群服务器系统性能瓶颈分析(zt).docx

《RAC数据库集群服务器系统性能瓶颈分析(zt).docx》由会员分享，可在线阅读，更多相关《RAC数据库集群服务器系统性能瓶颈分析(zt).docx（14页珍藏版）》请在课桌文档上搜索。

1、RAC数据库集群服务器系统性能瓶颈分析(Zt)OracleRAC性能调整1、CPU和waittime调整尺寸当在调整SyStem时，比较系统的CPUtime和Waittime是特别重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。从一般规律来看，waittime占主要部分的系统比CPUtime占主要部分的系统更须要调整。另一方面，CPU的大量运用可能是由不好的SQ1.写操作造成了。尽管CPUtime与waittime的比率总是随着系统装载的增加而趋于减小的，waittime的急剧增加是存在冲突的表现，必需被有效的处理。给node增加更多的CPUs或是给cl

2、uster增加nodes,在资源竞争中供应的benefit是特别有限的。相反，当加载系统装载增加时，CPUtime的比率没有大幅下降的系统可能规模较好，更可能通过添加CPUs或是RACInstances获得更多的benefitonote：假如CPUtime比率在前五个事务中，则automaticworkloadrepository(AWR)报告在Top5Event段中显示了CPU时间和wait时间。2、RAC特有的调整尽管对于RAC有其特有的调整方法，例如互联的传输，但通过对每个InStanCe进行像SingIe-InStanCe系统那样的调整会带来较大的beefito至少它应当tuning的

3、第一步。明显，假如在Single-InStanCe环境中存在序列化问题，在RAC中，该问题会更加严峻。RACTeaCtMe调整工具主要有：特定的等待事务、系统和队列统计、databasecontrol性能页面、StatSPaCk和AWR报告RAC-ProaCtiVe调整工具：AWRsnapshots、ADDM(AutomaticDatabaseDiagnosticMonitor)报告如上，RAC的调整工具和single-instance系统的基本类似。但部分特别等待事务和统计信息的结合是RAC比较关键的调整状况。3、分析在RAC中CaChefUSiOn(缓冲融合)的影响在全局缓冲中访问bloc

4、ks的影响和维护cache的相融合(coherency)是通过下面来表现的：*对当前和Crblocks的全局缓冲服务统计：例如，gc当前的blocksreceivedsgccrblocksreceived等。*全局缓冲服务等待事务(对gc当前block3-way、gccrgrant2-way)cachefusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议运用的messaging时间和processing时间确定的。除了相关的Iog写操作，它是不受磁盘I/O因素的影响的。cachefusion协议不须要对datafiles进行I/O,从而确保缓冲的Coherencyo并且RAC

5、并不会引起比非clusteredInstance更多的I/O操作。4、RAC操作特有的潜在因素在RACAWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cacheservices和全局队列services操作的平均时间。该表被称作是GlobalcacheandEnqueueservices:workloadCharacteristicSo这些潜在因素应当得到定期的监控，并且应当对部分值的重大增加进行调查。基于阅历视察，此表显示了一些代表值。引起这些潜在因素变更的因素主要有：*IPC协议的运用。用户模式的IPC协议更快*当系统在CPU高效运用的状况下，时序支配的延迟*对当前blocks

6、服务的logflush其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试特别有效。但无需进行常见的监控。note:处理缓存中一样读(ConSiStentreadCRjbIock的时间与(buildtime+flushtime+sendtime)一样；处理缓存中当前block恳求的时间与(pintime+flushtime+sendtime)一样。5、RAC的等待事务分析哪些SeSSiorIS在等待是一个确定时间开销在哪里的重要方法。在RAC中，等待时间主要归因于影响获得实际恳求结果的事务上。例如，当在某Instance上的一个session在Glo

7、balcache查询某个block,并不知道是否将收到CaChe在其他Instance中的data或是是否将获得从disk上读取的消息。对于Globalcache的等待事务反映了精确信息并等待全局缓冲block或是messageso它们主要是根据下述进行分类的：*在较广的分类的概括，被称作是clusterwaitclass*用占位符代表的临时事务，主要出现在bl。Ck的等待*当获得恳求结果的精确事务RAC的等待事务对性能分析是特别重要的。它们被应用于ADDM中，从而获得CaChefusion方面的精确诊断。1）等待事务视图对于一个事务的总的等待信息V$SYSTEM_EVENT一个session

8、的等待事务分类V$SESSION_WAIT_C1.ASS一个session等待的事务V$SESSlON_EVENT这三个视图汇合了等待时间、timeouts和特定事务等待次数。最近活动的sessions的活动行为V$ACTIVE_SESSION_HISTORY每个活动的session最近10个等待事务V$SESSION_WAIT_HISTORY活动的sessions正在等待的事务V$SESSION_WAIT受到互联因素影响的一样的SQ1.语句Vssqlarea这四个视图用于实时监控等待的sessions,包括最近的等待时间历史信息。通过其name和假设的参数，来区分单个事务自己。对于多数GIo

9、balCaChe等待事务，参数包括文件号、块号、块的类型和访问模式的配置（如held和request模式）。在这些视图中显示并统计的等待时间在调试相应时间时是特别有用的。留意，等待时间是累积计算的，有最大的该值的不肯定就是问题所在。但可用的CPU被占尽或是一个APPliCaHon的相应时间过长，top等待事务供应了有效的性能诊断信息。note：在V$SQ1.AREA中运用C1.USTER_WAIT_TIME字段辨别SQ1.语句受到互联因素的影响程度，或是在AWRsnapshot上执行一个ADDM报告。2)Globalcachewaitevent概览OracleDatabaseIOg中主要的Gl

10、obalcache等待事务的简要描述如下：*gccurretcrrequest:当一个进程访问须要一个或者多个块时,oracle会首先检查自己的CACHE是否存在该块,假如发觉没有，就会先通过globalcache给予这些块共享访问的权限，然后再访问。假如，通过globalcache发觉这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHEFUSQN,在节点之间干脆传递，同时出现globalcachecrrequest等待事务。CUrrent和Cr的不同，假如是读的话，那就是crrequest,假如是更改的话，那就是currentrequesto*gccurrent/cr23-w

11、ay:详细说明见后面实例*gccurrent/crblockbusy：一个current或是crblock被恳求并收到，但1.MS并没有马上发送，因为某些特定的推迟发送的状况被发觉。*gccurrent/crgrant2-way：当恳求一个block时，receive了一个message,该message应当是给予了requesterinstance可以访问这个block。假如这个block没有在localcache中，则随后的动作就是去磁盘上读该block。(插一点别的，OraCle的对数据的访问的限制，是在row级别和object级别，但是实际操作的对象却是block,传递的对象也是blo

12、ck,对于一个block,来说，会有一个masterinstance,也就是这个block的管理者，然后还有零到多个参加者，比如有的instance为了读一样性，可能会在自己的localcache中存着该block的过去某个时间的image,有的istace为了修改该block,可能会在自己的localcache中存着该block的pastimage）*gccurrentgrantbusy:当恳求一个currentblock时，收到grantmessageo该busy表示恳求被堵塞，主要是其他恳求在前面或是该恳求不能立刻被处理。*gccurrent/crblockgratcongested:无

13、论是对于current还是cr类型block的恳求，block或者grant都获得了，但是在过程中有拥堵。也就是在内部的队列中等待超过ImSeC（纳秒）。*gccurrent/crfailure/retry：一个bl。Ck被恳求，却收到失败的状态或是有其他意外事务的发生。*gcbufferbusy:对此，我的理解就是gc的内存不足，有大量的block恳求，须要等待将刚刚被pin入内存并运用的blockunpin后再运用。（似乎没理解对，看后面实例吧）3）2-wayblockrequest实例上图显示了当一个masterInstance恳求一个block,该block不在本地cache中时，详细

14、的操作。这里假设masterInstance为SGA1.SGA2中包含了恳求的block。详细如下:SGAl向SGA2干脆发送一个恳求，此时，SGAl发生gccurrentblockrequest等待事务当SGA2接到恳求，它的本地1.GWR进程须要flush部分复原信息到其本地redoIOg文件中。例如，假如缓冲的block被常见的修改，该修改尚未被写入Iog中，1.MS就须要在传输block前令1.GWR对log进行flush。这可能会增加一个延迟，可能在恳求的node上显示一个busywait。3随后，SGA2发送恳求的bl。Ck给SGA1。当该block到达SGA1.等待事务完成，这被

15、反映为gscurrentblock2-wayonote：假如R表示在恳求者的time,W为消息传输的time延迟，S为在SerVer的time。则整个来回的总时间为：R(send)+W(smallmsg)+S(processmsg,pocessblock,send)+W(block)+R(receiveblock)4)3-wayblockrequest的实例在此，与上一个实例不同的就是block的恳求者与block的master,block的缓冲不在同一个node上。所以总体时间为：R(send)+Wfsmallmsg)+S(processmsg,send)+W(smallmsg)+S(pro

16、cessmsg,processblock,send)+W(block)+R(receiveblock)当远程读被挂起，任何在恳求InStanCe上的尝试读写缓冲在buffer中的data的进程将等待gcbufferbusy事务，直到block到达。5)2-waygrant实例6)considered“1.ost“Blocks实例如图，此状况为：在恳求的block到达前先收到了sidechannelmessage。在一般环境中，这是不会发生的。多数状况下它是转换问题的显示或是缺少私有互联。这常与OS或是网络的配置问题有关。note：可尝试避开此类现象的发生，通过减小参数D

17、B_Fl1.EJvlU1.TlB1.OCK_READ_COUNT的值，使其低于16o7)Global队列等待overview队列等待并不是RAC特有的，但是在RAC环境中涉及到GIobalI。Ck的操作。多数对队列的Global恳求是同步的，并且有前台进程等待。因此，队列冲突在RAC环境中更明显。多数队列等待发生在下列类型的队列：*TX：transaction队列，用于事务的划分和追踪*TMKable或是Partition队列，用于爱护DM1.执行期间table的定义*HW:高水位线队列，取得用于新的block操作的同步*SQ:sequence队列，用于Oraclesequencenumber

18、的序列化增加*US:undosegment队列，主要用于自动Undo管理(AUM)的特性*TA：主要用于事务复原的队列上述状况下，等待是同时的，可能造成严峻的序列化,从而导致RAC环境的恶化。6、SeSSiOn和SyStem统计运用基于V$SYSSTAT的系统统计使得基于平均的Danbase描述成为可能。它是许多通过各种工具和方法获得Database的度量和比率的基础，例如AWR、Statspack和Databasecontrolo为了进一步对sessions进行深化的了解，VSSESSTAT视图是特别有用的。此外，假如运用了MoDU1.E、ACTloN模式的统计，将更有效。V$SEGMENT

19、_STATISTICS对于RAC环境也特别重要,因为它跟踪了CR的数量以及object当前获得的blocksRAC相关的统计可以被分为以下几组：*Globalcacheservice统计:gccrblocksreceived,gccrblockrecevietime等*GlobalEnqueueservice统计：globalenqueuegets等*messages发送的统计：gcsmessagessent和gesmessagessent可以通过查询V$ENQUEUE_STATISTICS确定哪个队列对DatabaSeservice时间和最终的响应时间有最大的影响。V$INSTANCE_CA

20、CHE_TRANSFER显示了每个block类中有多少current和CRblocks从Instance中接受，包括多少传输引起延迟。7、RACtUning的tips首先，在RAC环境中，必需先利用传统的调整技术对每个InS【ance进行调整，此外，下面的内容也很重要：*尽量避开较长的全表扫描来缩小GCS的恳求。由GlobalCR恳求引起的开支主要是因为当所查询的结果在本地cache中不存在，先尝试在其他cache中尝试找到相应数据。*自动段空间管理可以给tableblocks供应InStanCe关联(affinity)*增力口SeqUenCeS的caches改善Instance关联的通过se

21、quences获得索引关键字的值的性能。*当把range或是list类型的partitioning和data-dependetrouting相结合，可以有效的提高性能。*hashpartitioning可有效降低bufferbusy的冲突，使得buffer访问分布格局松散，可以使buffers用于更多的并发访问。*在RAC中，librarycache和rowCaChe操作都是全局协调的。所以过度的解析意味着额外的互联传输。当packages或是procedure须要被重新编译时，须要以排他模式获得IibraryCaCheIOCks。*因为transaCtionIOCkS是全局协调的,在RAC中

22、,也应的到特别的对待。例如运用tables代替OraCIesequences产生唯一numbers是不举荐的，可能引起严峻的冲突，即使是在singleInstance系统中。*选择性不好的indexes不会提高查询性能，反而会降低DM1.操作的性能。在RAC环境中，Unselectiveindexblocks可能导致Instance间的冲突，增加cache对indexes传输的的频度。8Jndexblock冲突的思索由于index多数是单调递增的，往往造成热块争用的问题；而且对于大量的insert操作,可能引起常见的splits；全部leafblock的访问都是通过rootblock的。所以i

23、ndex可能造成性能的降低对此：*全局索弓IhaShPartitiOning*增力口sequencecache,假如必要的话9、undoblock考虑当indexblocks包含了从多个Instances发起的事务被常见的读，过度的undoblock传输和undobuffers的争用常常会发生。当一个select语句须要读取一个block,该block正被一个active的事务运用，就不得不用undo来重建一个CR版本。假如block所在的active事务属于不只一个Instance,则须要结合本地和远程undoinformation用于一样读，依据被多个Instances修改的indexbl

24、ocks的数量和transaction的并发，undoblock的传输可能成为瓶颈。这多发生在频繁读取近期插入的数据但提交不常见的应用中。对此应：*运用ShOrtertranSaCtiOn从而降低这样的可能性：从cache中获得的indexblock含有未提交的data,从而降低访问UndOinformation用于一样读的可能*增加sequencecachesize,从而削减须要进行远程UndO信息组合的需求。10、高水位线的考虑数据的insert操作是业务领域的主要功能，新的blocks须要常见的安排给Segment。假如daa的insert操作比率较高，假如没有找到空闲空间时，须要申请新

25、的blocks0这须要获得相应的high-watermark(HWM)队列。因此，最为普遍的状况为：*较高比率的队列等待时间enq:HW–contention*较高比率的等待时间对于gccurrentgrantevents前者是HWM队列序列化的结果，后者是由于当前访问新的datablocks是须要对新的blocks进行操作。在RAC环境中，这个空间管理操作的时间长短是与获得HW队列和获得全部新的blocks的Globallocks所用的时间成比例的。这个时间在一般环境中比较小，因为在访问新的blocks时是不存在任何冲突的。然而，这种冲突可能会出现在有大量dataIOad的业务需

26、求中。对此，建议在本地管理及自动空间管理segments中定义一样的较大的extentsize,从而适当解决相应的问题。11、automaticworkloadrepository1)overviewAWR是OraCIeDatabaseIOg供应的基础服务工具，用于收集、维护和应用统计信息来检测问题并进行自我的调整。AWR主要由两部分组成：*一个在内存的统计收集设施,由OracleDatabaseIOg运用并收集统计信息。这些统计被存储在内存中，可以通过动态性能视图查看到(V$)*AWRsnapshots代表了设备的长久部分。可以通过datadictionary视图和DatabaSecontr

27、ol来访问C处于以下几个缘由，统计须要保存在永久的设备中：*统计须要用于激活InStanCeCraSheS*一些分析须要历史数据作为基线的比较*内存的溢出：当由于内存不足，旧的统计数据须要被新的统计数据替换时，可以将旧的统计数据存储在磁盘上以备后用统计的内存版本由新的后台进程manageabilitymonitor(MMON)定期的传输的disk上。通过AWR,OracleDatabase供应了自动捕获历史统计data的方法，无需DBA干涉。2)AWRtabIesAWR包括两类表：*元数据表：用于限制、处理、描述AWR表。例如，OracleDatabase运用元数据表来确定何时执行snapsh

28、ots,并将什么数据捕获到disk上。此外，元数据包含了SnaPShots_id和相应通讯时间之间的映射。*历史统计表：存储了OraCieDatabase的历史统计信息。每个Sn叩ShOtS就是在特定时间点捕获的内存中的Database统计数据。AWR表的names都有一个WRX$前缀,其中X指明白tables的种类：*WRM$表存储了AWR中的元数据*WRH$表中存储了历史数据和snapshots可以是运用字典视图来查询AWR数据。在AWR中任何相关的历史信息有DBA_HIST_的前缀AWR运用分区用于有效的查询和数据的清理。SnaPShOIStabIeS是根据以下分类组织的:file统计、

29、一般系统统计、并发统计、InStanCe调整统计、SQ1.统计、segment统计、undo统计、time-model统计、复原统计和RAC统计。3）在RAC中的AWRSn叩ShotS在RAC环境中，每个AWRSnaPShol是从全部的活动的InStanCeS获得data的。从每个活动的Instances获得的每个snapshot数据集合是大致来自相同的时间点的。此外，每个InStanCe的数据是单独存储的，是以Instance的标识符来区分的。例如，buffer_busy_wait统计显示了在每个InStanCe上bufferwaits的次数。AWR不会存储ClUSter中的合计数据。换句话

30、说，data是存放在各自的Instance上的。由AWR产生的统计Sn叩ShOtS可以用于评估、产生报告显示data摘要。12、Statspack和AWR可以通过手工的对StatSPaCk操作获得历史统计数据。但是将Statspack获得的数据迁移到AWR中是不支持的，也不存在为其创建的视图13、AutomaticDatabasediagnosismonitor默认下，Database每隔60分钟，会自动的从SGA中捕获相应的统计信息，并将其以SnaPShOtS的形式存储在AWR中。这些snapshots被存储在disk上，和Statspacksnapshots是一样的，但比StatSPaCk的信息更精确,此外，ADDM是通过在每个DatabaseInstance中的新的MMON进程自动运行相应的支配，来主动找到问题的所在。每次获得一个SnaPShOt。ADDM会被触发执行一个与上一个snapshots进行阶段一样性比较的操作。每个ADDM分析被存储在AWR中（WR1$表）也可通过EM访问。1）ADDM问题分类ADDM运用树形结构代表全部可能须要调整的问题。该tree是基于新的等待和时间统计模式的。树根代表的是Database当前的症状。