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

RAC数据库集群服务器系统性能瓶颈分析(zt)Oracle RAC性能调整1、CPU和wait time调节尺寸当在调节system时，比较系统的CPU time 和wait time是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。

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

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

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

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

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

note：如果CPU time比率在前五个事件中，则automatic workload repository（AWR）报告在Top 5 Event 段中显示了CPU时间和wait 时间。

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

至少它应该tuning的第一步。

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

RAC-reactive调节工具主要有：特定的等待事件、系统和队列统计、database control 性能页面、statspack和AWR 报告RAC-proactive调节工具：AWR snapshots、ADDM（Automatic Database Diagnostic Monitor）报告如上，RAC的调节工具和single-Instance 系统的基本类似。

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

3、分析在RAC中cache fusion（缓冲融合）的影响在全局缓冲中访问blocks的影响和维护cache的相融合（coherency）是通过下面来表现的：* 对当前和cr blocks的全局缓冲服务统计：例如，gc当前的blocks received、gc cr blocks received等。

* 全局缓冲服务等待事件（对gc 当前block 3-way、gc cr grant 2-way等）cache fusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议使用的messaging时间和processing 时间决定的。

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

cache fusion 协议不需要对data files进行I/O，从而确保缓冲的coherency。

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

4、RAC操作特有的潜在因素在RAC AWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cache services和全局队列services操作的平均时间。

该表被称作是Global cache and Enqueue services: workload characteristics。

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

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

引起这些潜在因素变更的因素主要有：* IPC协议的使用。

用户模式的IPC协议更快* 当系统在CPU高效使用的情况下，时序安排的延迟* 对当前blocks 服务的log flush 其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试非常有效。

但无需进行频繁的监控。

note：处理缓存中一致读（consistent read CR）block的时间与（build time+flush time+send time）一致；处理缓存中当前block请求的时间与（pin time+ flush time+ send time）一致。

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

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

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

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

它们主要是按照下述进行分类的：* 在较广的分类的概括，被称作是cluster wait class * 用占位符代表的临时事件，主要出现在block的等待* 当获得请求结果的精确事件RAC的等待事件对性能分析是非常重要的。

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

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和假设的参数，来区分单个事件自己。

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

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

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

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

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

2）Global cache wait event概览Oracle Database 10g中主要的Global cache等待事件的简要描述如下：* gc current/cr request：当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。

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

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

* gc [current/cr] [2/3]-way：具体解释见后面实例* gc [current/cr] block busy：一个current 或是cr block被请求并收到，但LMS并没有立即发送，因为某些特定的推迟发送的情况被发现。

* gc [current/cr] grant 2-way：当请求一个block时，receive了一个message，该message应该是赋予了requester instance可以访问这个block。

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

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

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

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

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

* gc [current/cr] [failure/retry]：一个block被请求，却收到失败的状态或是有其他意外事件的发生。

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

（好像没理解对，看后面实例吧）3）2-way block request实例上图显示了当一个master Instance请求一个block，该block 不在本地cache中时，具体的操作。

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

具体如下：①SGA1向SGA2直接发送一个请求，此时，SGA1发生gc current block request等待事件②当SGA2接到请求，它的本地LGWR进程需要flush 部分恢复信息到其本地redo log文件中。

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

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

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

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