ORACLE性能.docx

ORACLE性能.docx

《ORACLE性能.docx》由会员分享，可在线阅读，更多相关《ORACLE性能.docx（14页珍藏版）》请在冰豆网上搜索。

ORACLE性能

详解OracleRAC性能调整

当在调节system时，比较系统的CPUtime和waittime是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。

　　1、CPU和waittime调节尺寸

　　当在调节system时，比较系统的CPUtime和waittime是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。

　　从一般规律来看，waittime占主要部分的系统比CPUtime占主要部分的系统更需要调节。

另一方面，CPU的大量使用可能是由不好的SQL写操作造成了。

　　尽管CPUtime与waittime的比率总是随着系统装载的增加而趋于减小的，waittime的急剧增加是存在冲突的表现，必须被有效的处理。

　　给node增加更多的CPUs或是给cluster增加nodes，在资源竞争中提供的benefit是非常有限的。

相反，当加载系统装载增加时，CPUtime的比率没有大幅下降的系统可能规模较好，更可能通过添加CPUs或是RACInstances获得更多的benefit。

　　note：

如果CPUtime比率在前五个事件中，则automaticworkloadrepository（AWR）报告在Top5Event段中显示了CPU时间和wait时间。

　　2、RAC特有的调节

　　尽管对于RAC有其特有的调节方法，例如互联的传输，但通过对每个Instance进行像single-Instance系统那样的调节会带来较大的benefit。

至少它应该tuning的第一步。

　　显然，如果在single-Instance环境中存在序列化问题，在RAC中，该问题会更加严重。

　　RAC-reactive调节工具主要有：

特定的等待事件、系统和队列统计、databasecontrol性能页面、statspack和AWR报告

　　RAC-proactive调节工具：

AWRsnapshots、ADDM（AutomaticDatabaseDiagnosticMonitor）报告

　　如上，RAC的调节工具和single-Instance系统的基本类似。

但部分特殊等待事件和统计信息的结合是RAC比较关键的调节情况。

3、分析在RAC中cachefusion（缓冲融合）的影响

　　在全局缓冲中访问blocks的影响和维护cache的相融合（coherency）是通过下面来表现的：

　　*对当前和crblocks的全局缓冲服务统计：

例如，gc当前的blocksreceived、gccrblocksreceived等。

　　*全局缓冲服务等待事件（对gc当前block3-way、gccrgrant2-way等）

　　cachefusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议使用的messaging时间和processing时间决定的。

　　除了相关的log写操作，它是不受磁盘I/O因素的影响的。

cachefusion协议不需要对datafiles进行I/O，从而确保缓冲的coherency。

并且RAC并不会引起比非clusteredInstance更多的I/O操作。

　　4、RAC操作特有的潜在因素

　　在RACAWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cacheservices和全局队列services操作的平均时间。

该表被称作是GlobalcacheandEnqueueservices:

workloadcharacteristics。

这些潜在因素应该得到定期的监控，并且应该对部分值的重大增加进行调查。

基于经验观察，此表显示了一些代表值。

引起这些潜在因素变更的因素主要有：

　　*IPC协议的使用。

用户模式的IPC协议更快

　　*当系统在CPU高效使用的情况下，时序安排的延迟

　　*对当前blocks服务的logflush

　　其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试非常有效。

但无需进行频繁的监控。

　　note：

处理缓存中一致读（consistentreadCR）block的时间与（buildtime+flushtime+sendtime）一致;处理缓存中当前block请求的时间与（pintime+flushtime+sendtime）一致。

　　5、RAC的等待事件

　　分析哪些sessions在等待是一个确定时间开销在哪里的重要方法。

在RAC中，等待时间主要归因于影响获得实际请求结果的事件上。

例如，当在某Instance上的一个session在Globalcache查询某个block，并不知道是否将收到cache在其他Instance中的data或是是否将获得从disk上读取的消息。

对于Globalcache的等待事件反映了准确信息并等待全局缓冲block或是messages。

它们主要是按照下述进行分类的：

　　*在较广的分类的概括，被称作是clusterwaitclass

　　*用占位符代表的临时事件，主要出现在block的等待

　　*当获得请求结果的精确事件

　　RAC的等待事件对性能分析是非常重要的。

它们被应用于ADDM中，从而获得cachefusion方面的精确诊断。

　　1）等待事件视图

　　对于一个事件的总的等待信息——V$SYSTEM_EVENT

　　一个session的等待事件分类——V$SESSION_WAIT_CLASS

　　一个session等待的事件——V$SESSION_EVENT

　　这三个视图汇集了等待时间、timeouts和特定事件等待次数。

　　最近活动的sessions的活动行为——V$ACTIVE_SESSION_HISTORY

　　每个活动的session最近10个等待事件——V$SESSION_WAIT_HISTORY

　　活动的sessions正在等待的事件——V$SESSION_WAIT

　　受到互联因素影响的一致的SQL语句——V$SQLAREA

　　这四个视图用于实时监控等待的sessions，包括最近的等待时间历史信息。

　　通过其name和假设的参数，来区分单个事件自己。

对于多数Globalcache等待事件，参数包括文件号、块号、块的类型和访问模式的配置（如held和request模式）。

在这些视图中显示并统计的等待时间在调试相应时间时是非常有用的。

注意，等待时间是累积计算的，有最大的该值的不一定就是问题所在。

但可用的CPU被占尽或是一个Application的相应时间过长，top等待事件提供了有效的性能诊断信息。

　　note：

在V$SQLAREA中使用CLUSTER_WAIT_TIME字段辨别SQL语句受到互联因素的影响程度，或是在AWRsnapshot上执行一个ADDM报告。

　　2）Globalcachewaitevent概览

　　OracleDatabase10g中主要的Globalcache等待事件的简要描述如下：

　　*gccurrent/crrequest：

当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过globalcache赋予这些块共享访问的权限，然后再访问。

假如，通过globalcache发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHEFUSION,在节点之间直接传递，同时出现globalcachecrrequest等待事件。

current和cr的不同，如果是读的话，那就是crrequest，如果是更改的话，那就是currentrequest。

　　*gc[current/cr][2/3]-way：

具体解释见后面实例

　　*gc[current/cr]blockbusy：

一个current或是crblock被请求并收到，但LMS并没有立即发送，因为某些特定的推迟发送的情况被发现。

　　*gc[current/cr]grant2-way：

当请求一个block时，receive了一个message，该message应该是赋予了requesterinstance可以访问这个block。

如果这个block没有在localcache中，则随后的动作就是去磁盘上读该block。

（插一点别的，oracle的对数据的访问的控制，是在row级别和object级别，但是实际操作的对象却是block，传递的对象也是block，对于一个block，来说，会有一个masterinstance，也就是这个block的管理者，然后还有零到多个参与者，比如有的instance为了读一致性，可能会在自己的localcache中存着该block的过去某个时间的image，有的instace为了修改该block，可能会在自己的localcache中存着该block的pastimage）

*gccurrentgrantbusy：

当请求一个currentblock时，收到grantmessage。

该busy表示请求被阻塞，主要是其他请求在前面或是该请求不能马上被处理。

　　*gc[current/cr][block/grant]congested：

无论是对于current还是cr类型block的请求，block或者grant都获得了，但是在过程中有拥堵。

也就是在内部的队列中等待超过1msec（纳秒）。

　　*gc[current/cr][failure/retry]：

一个block被请求，却收到失败的状态或是有其他意外事件的发生。

　　*gcbufferbusy：

对此，我的理解就是gc的内存不足，有大量的block请求，需要等待将刚刚被pin入内存并使用的blockunpin后再使用。

（好像没理解对，看后面实例吧）

　　3）2-wayblockrequest实例

　　上图显示了当一个masterInstance请求一个block，该block不在本地cache中时，具体的操作。

这里假设masterInstance为SGA1，SGA2中包含了请求的block。

具体如下：

　　①SGA1向SGA2直接发送一个请求，此时，SGA1发生gccurrentblockrequest等待事件

　　②当SGA2接到请求，它的本地LGWR进程需要flush部分恢复信息到其本地redolog文件中。

例如，如果缓冲的block被频繁的修改，该修改尚未被写入log中，LMS就需要在传输block前令LGWR对log进行flush。

这可能会增加一个延迟，可能在请求的node上显示一个busywait。

　　③随后，SGA2发送请求的block给SGA1。

当该block到达SGA1，等待事件完成，这被反映为gscurrentblock2-way。

　　note：

如果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）+W（smallmsg）+S（processmsg,send）+W（smallmsg）+S（processmsg,processblock,send）+W（block）+R（receiveblock）

　　当远程读被挂起，任何在请求Instance上的尝试读写缓冲在buffer中的data的进程将等待gcbufferbusy事件，直到block到达。

　　5）2-waygrant实例

　　6）considered“Lost“Blocks实例

　　如图，此情况为：

在请求的block到达前先收到了sidechannelmessage。

在普通环境中，这是不会发生的。

多数情况下它是转换问题的显示或是缺少私有互联。

这常与OS或是网络的配置问题有关。

　　note：

可尝试避免此类现象的发生，通过减小参数DB_FILE_MULTIBLOCK_READ_COUNT的值，使其低于16。

　　7）Global队列等待overview

　　队列等待并不是RAC特有的，但是在RAC环境中涉及到Globallock的操作。

多数对队列的Global请求是同步的，并且有前台进程等待。

因此，队列冲突在RAC环境中更明显。

多数队列等待发生在下列类型的队列：

　　*TX：

transaction队列，用于事务的划分和追踪

　　*TM：

table或是partition队列，用于保护DML执行期间table的定义

　　*HW：

高水位线队列，取得用于新的block操作的同步

　　*SQ：

sequence队列，用于Oraclesequencenumber的序列化增加

　　*US：

undosegment队列，主要用于自动undo管理（AUM）的特性

　　*TA：

主要用于事务恢复的队列

　　上述情况下，等待是同时的，可能造成严重的序列化，从而导致RAC环境的恶化。

　6、session和system统计

　　使用基于V$SYSSTAT的系统统计使得基于平均的Database描述成为可能。

它是很多通过各种工具和方法获得Database的度量和比率的基础，例如AWR、statspack和Databasecontrol。

　　为了进一步对sessions进行深化的了解，V$SESSTAT视图是非常有用的。

此外，如果使用了MODULE、ACTION模式的统计，将更有效。

　　V$SEGMENT_STATISTICS对于RAC环境也非常重要，因为它跟踪了CR的数量以及object当前获得的blocks

　　RAC相关的统计可以被分为以下几组：

　　*Globalcacheservice统计：

gccrblocksreceived,gccrblockrecevietime等

　　*GlobalEnqueueservice统计：

globalenqueuegets等

　　*messages发送的统计：

gcsmessagessent和gesmessagessent

　　可以通过查询V$ENQUEUE_STATISTICS确定哪个队列对Databaseservice时间和最终的响应时间有最大的影响。

　　V$INSTANCE_CACHE_TRANSFER显示了每个block类中有多少current和CRblocks从Instance中接受，包括多少传输引起延迟。

　　7、RACtuning的tips

　　首先，在RAC环境中，必须先利用传统的调节技术对每个Instance进行调节，此外，下面的内容也很重要：

　　*尽量避免较长的全表扫描来缩小GCS的请求。

由GlobalCR请求引起的开支主要是因为当所查询的结果在本地cache中不存在，先尝试在其他cache中尝试找到相应数据。

　　*自动段空间管理可以给tableblocks提供Instance关联（affinity）

　　*增加sequences的caches改善Instance关联的通过sequences获得索引关键字的值的性能。

　　*当把range或是list类型的partitioning和data-dependentrouting相结合，可以有效的提高性能。

　　*hashpartitioning可有效降低bufferbusy的冲突，使得buffer访问分布格局松散，可以使buffers用于更多的并发访问。

　　*在RAC中，librarycache和rowcache操作都是全局协调的。

所以过度的解析意味着额外的互联传输。

当packages或是procedure需要被重新编译时，需要以排他模式获得librarycachelocks。

　　*因为transactionlocks是全局协调的，在RAC中，也应的到特殊的对待。

例如使用tables代替Oraclesequences产生唯一numbers是不推荐的，可能引起严重的冲突，即使是在singleInstance系统中。

　　*选择性不好的indexes不会提高查询性能，反而会降低DML操作的性能。

在RAC环境中，unselectiveindexblocks可能导致Instance间的冲突，增加cache对indexes传输的的频度。

8、indexblock冲突的思考

　　由于index多数是单调递增的，往往造成热块争用的问题;而且对于大量的insert操作，可能引起频繁的splits;所有leafblock的访问都是通过rootblock的。

所以index可能造成性能的降低。

对此：

　　*全局索引hashpartitioning

　　*增加sequencecache，如果必要的话

　　9、undoblock考虑

　　当indexblocks包含了从多个Instances发起的事务被频繁的读，过度的undoblock传输和undobuffers的争用经常会发生。

当一个select语句需要读取一个block，该block正被一个active的事务使用，就不得不用undo来重建一个CR版本。

如果block所在的active事务属于不只一个Instance，则需要结合本地和远程undoinformation用于一致读，依据被多个Instances修改的indexblocks的数量和transaction的并发，undoblock的传输可能成为瓶颈。

　　这多发生在频繁读取近期插入的数据但提交不频繁的应用中。

对此应：

　　*使用shortertransaction从而降低这样的可能性：

从cache中获得的indexblock含有未提交的data，从而降低访问undoinformation用于一致读的可能

　　*增加sequencecachesize，从而减少需要进行远程undo信息组合的需求。

　　10、高水位线的考虑

　　数据的insert操作是业务领域的主要功能，新的blocks需要频繁的分配给segment。

如果data的insert操作比率较高，如果没有找到空闲空间时，需要申请新的blocks。

这需要获得相应的high-watermark（HWM）队列。

　　因此，最为普遍的状况为：

　　*较高比率的队列等待时间enq:

HW–contention

　　*较高比率的等待时间对于gccurrentgrantevents

　　前者是HWM队列序列化的结果，后者是由于当前访问新的datablocks是需要对新的blocks进行操作。

在RAC环境中，这个空间管理操作的时间长短是与获得HW队列和获得所有新的blocks的Globallocks所用的时间成比例的。

这个时间在普通环境中比较小，因为在访问新的blocks时是不存在任何冲突的。

然而，这种冲突可能会出现在有大量dataload的业务需求中。

对此，建议在本地管理及自动空间管理segments中定义一致的较大的extentsize，从而适当解决相应的问题。

11、automaticworkloadrepository

　　1）overview

　　AWR是OracleDatabase10g提供的基础服务工具，用于收集、维护和应用统计信息来检测问题并进行自我的调节。

　　AWR主要由两部分组成：

　　*一个在内存的统计收集设施，由OracleDatabase10g使用并收集统计信息。

这些统计被存储在内存中，可以通过动态性能视图查看到（V$）

　　*AWRsnapshots代表了设备的持久部分。

可以通过datadictionary视图和Databasecontrol来访问。

　　处于以下几个原因，统计需要保存在永久的设备中：

　　*统计需要用于激活Instancecrashes

　　*一些分析需要历史数据作为基线的比较

　　*内存的溢出：

当由于内存不足，旧的统计数据需要被新的统计数据替换时，可以将旧的统计数据存储在磁盘上以备后用

　　统计的内存版本由新的后台进程manageabilitymonitor（MMON）定期的传输的disk上。

通过AWR，OracleDatabase提供了自动捕获历史统计data的方法，无需DBA干涉。

　　2）AWRtables

　　AWR包括两类表：

　　*元数据表：

用于控制、处理、描述AWR表。

例如，OracleDatabase使用元数据表来确定何时执行snapshots，并将什么数据捕获到disk上。

此外，元数据包含了snapshots_id和相应通讯时间之间的映射。

　　*历史统计表：

存储了OracleDatabase的历史统计信息。

每个snapshots就是在特定时间点捕获的内存中的Database统计数据。

　　AWR表的names都有一个WRx$前缀，其中x指明了tables的种类：

　　*WRM$表存储了AWR中的元数据

　　*WRH$表中存储了历史数据和snapshots

　　可以是使用字典视图来查询AWR数据。

在AWR中任何相关的历史信息有DBA_HIST_的前缀

　　AWR使用分区用于有效的查询和数据的清理。

snapshotstables是按照以下分类组织的：

file统计、一般系统统计、并发统计、Instance调节统计、SQL统计、segment统计、undo统计、time-model统计、恢复统计和RAC统计。

　　3）在RAC中的AWRsnapshots

　　在RAC环境中，每个AWRsnapshot是从所有的活动的Instances获得data的。

从每个活动的Instances获得的每个snapshot数据集合是大致来自相同的时间点的。

此外，每个Instance的数据是单独存储的，是以Instance的标识符来区分的。

例如，buffer_busy_wait统计显示了在每个Instance上bufferwaits的次数。

AWR不会存储cluster中的合计数据。

换句话说，data是存放在各自的Instance上的。

　　由AWR产生的统计snapshots可以用于评估、产生报告显示data摘要。

　　12、statspack和AWR

　　可以通过手工的对statspack操作获得历史统计数据。

但是将statspack获得的数据迁移到AWR中是不支持的，也不存在为其创建的视图

　　13、AutomaticDatabasediagnosismonitor

　　默认下，Database每隔60分钟，会自动的从SGA中捕获相应的统计信息，并将其以snapshots的形式存储在AWR中。

这些snapshots被存储在disk上，和statspacksnapshots是一致的，但比statspack的信息更精