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：可尝试避开此类现象的发生，通过减小参数DB_Fl1.EJvlU1.TlB1.OCK_READ_COUNT的值，使其低于16o7)Global队列等待overv