文章中的图片显示不出来，在文章后面有Word文档，可以参考。

1.主要问题

两个实例之间的业务负载非常不均衡，造成实例的效率下降。

1.1实例之间的负载不均衡，且负载较高的实例并不固定

较高的负载可能集中在实例1，也可能是另一个实例。

2015年1月26日：

2015年1月27日：

1.2.实例效率下降

ü  Cluster类相关的等待占整个DBTime的10%以上，直白的显示出RAC存在一定问题。

ü  USER I/O相关的两个等待都是与DB File相关的，在接下来的分析中我们会发现，它们与Cluster等待都源自相同的原因。

ü  CPU占比较高，提示我们，可能可以通过减少CPU的占用提高整个实例的效率。

2.原因分析

2.1TOP5等待事件的原因

由于硬解析较高，并且，采用了自动自动共享内存管理（ASMM），Shareool被自动调整到很大的值，导致DataBuffer缩小，从而，造成了DataFile的物理读增加（表现为TOP5等待事件中的DBFile等待事件）和实例之间的远程获取增加（表现为TOP5等待事件中的Cluster相关的等待增加）。

同时，硬解析和GC活动的增加也会导致CPU增加。

以上原因造成了单个实例的Top5等待事件。

2.2实例的负载差异原因

那么，负载在两个实例之间为什么会差异如此巨大呢？

由于ASMM的关系，两个实例在分配SharePool和DataBuffer时比例是不同的。为了得到平衡的CPU使用率，Oracle针对事务的不同特点，在实例之间进行了平衡。从而，最终，两个实例的DBTime最然差异巨大，但CPU时间却相差不多。本质上，真正平衡的使用了两个实例的资源。

换个说法，如果Oracle数据库，没有重新根据事务特点分配工作量，那么即便是内存比例不同的实例，也会得到相同的工作，最终，就会造成，两个实例上CPU使用的不平衡，工作量虽然是均衡的，但资源却并不能与执行的任务相匹配。

也就是说，Oracle的负载均衡是考虑到了内存的分配情况的后的结果，而不是简单的把任务平均分配给每个实例。Oracle的均衡更倾向于CPUTime的均衡而不是DBTime。

2.3分析过程

2.3.1两个实例上完成的事务特点不同

从以下数据，我们发现，两个实例上完成的事务，其特点是不同的。

实例1上，每个事务的RedoSize大约44K，而BufferCache于SharePool的比例大约是5:5

实例2上，每个事务的RedoSize大约不到18K，而BufferCache于SharePool的比例大约是5:3

比较以上数据，发现：实例1的事务更倾向于DML，而实例2上的事务更倾向于查询。

实例1的DBTime明显比实例2多，而DataBuffer的比例明显偏少。

2.3.2 RAC的负载均衡是指CPUTime百分比的均衡

我们发现另一个有意思的现象，就是下面的数据显式，两个实例的CPUTime的百分比非常接近。

这说明RAC的负载均衡在这两个实例上一直以一种稳定的方式运行，这种方式就是以CPUTime百分比为目标的在两个 实例之间作均衡。这也解释了，为什么在负载均衡机制下，两个实例的DBTime差异那么明显，因为均衡不是以DBTime为目标的。

不同实例的内存的分配比例不同，等待事件的影响也不同，为了在实例之间平衡CPUTime的百分比，就需要每个实例运行不同特点的事务，从而弥补那些差异。这也就解释了，为什么我们会发现，两个实例上的事务特点不同，一个倾向于DML，另一个倾向于查询。

下面有一些汇总的数据，可以发现，CPUTime%在不同实例上基本上是相等的。

2.3.3自动共享内存管理和RAC负载均衡

为什么DataBuffer和SharePool大小的比例在这两个实例上会不同呢？原因如下：

ü  每个实例可以设置自己的内存。

ü  从Oracle10g开始，ASMM机制会根据事务对内存的需求，对共享内存（其中就包括DataBuffer和SharePool）自动调整。

ü  较高的硬解析率造成其对SharePool的需求较大。

ü  负载均衡的目标是CPUTime的均衡，因此，在每个实例的事务特点会不同，对SharePool的需求也就不同。

ü  Sga_target限制了总的共享内存大小，目前来看，此值设置的过小

也就说，当应解析率较高时，会要求较多的SharePool，但因为总的共享内存是有限的，DataBuffer就不得不减少。又因为每个实例上的事务特点不同，运行的SQL对SharePool的需求也就不同，最终，造成了SharePool在每个实例上都不同。Oracle根据负载平衡的目标，开始在两个实例上分配不同的事务。这可能进一步加剧了共享内存的自动分配，使得dataBuffer 和SharePool进一步变化。在一开始时，可能这种差异并不明显，但ASMM和RAC的负载均衡机制反复相互作用，最后，在运行一段时间后，这种差异就变得比较明显了，CPUTime终于取得了平衡。但是事务在一段时间后是会变化的，这会造成新的不平衡。

也正是这个过程，造成了共享内存内部的分配比例不稳定，一段时间后，平衡被打破，ASMM将重新分配共享内存，这就造成了我们看到的现象：高DBTime的实例并不固定。

以下是具体数据：

实例1和实例2的参数文件中显示的sga_target设置是一样的，大概9.5G左右。

BufferCache和SharePool在每个实例上的总大小都是9G多一点，其中一个增加，另一个就会减少，总量不变。

以下是两个实例在DBTime较高时，显示出硬解析率较高，LibraryHit很低，同时我们从之前的分析了解到，SharePool大小的比例已经很高。高硬解析率对SharePool造成了较大需求，将DataBuffer挤压的很小，造成此处看到的BufferHit较低。

在对共享内存的 建议中，我们看到目前的尺寸的确太小。

关于实例1的建议，DataBuffer建议为8960兆，SharePool建议为5968兆，两者之和为15G，考虑到其他内存结构，最后建议SGA大小为16G：

关于实例2的建议，DataBuffer建议为12160兆，SharePool建议为4480兆，两者之和为16.5G，考虑到其他内存结构，最后建议SGA大小为17G：

3.建议

3.1解决硬解析

如果硬解析可以减少，就可以降低对SharePool的需求，从而给DataBuffer留出空间，提高内存命中率，减少IO和gc活动。同时，由于减少了ASMM对内存的调整，也可以降低CPU消耗。

当解决硬解析后，可以再采集一次AWR报告，观察一下其中关于DataBuffer和SharePool的建议，看看内存是否合理，是否够用。

以下语句可以查询硬解析的SQL有哪些：

with force_mathces as
(select l.force_matching_signature mathces,
max(l.sql_id || l.child_number) max_sql_child,
dense_rank() over(order by count(*) desc) ranking
from v$sql l
where l.force_matching_signature <> 0
and l.parsing_schema_name <> 'SYS'
group by l.force_matching_signature
having count(*) > 10)
select v.sql_id, v.sql_text, v.parsing_schema_name, fm.mathces, fm.ranking
from force_mathces fm, v$sql v
where fm.max_sql_child = (v.sql_id || v.child_number)
and fm.ranking <= 5
order by fm.ranking;

3.2设置DataBuffer和SharePool的最小值

如果内存合理，为了不让ASMM过度的调整内存，可以为DataBuffer和SharePool设置最小值。

可以执行如下命令：

Alter system set db_cache_size=XXXM Scope=Both

Alter system set share_pool_size=XXXM Scope=Both

3.3如果解决硬解析后，内存仍不够用，可以增加共享内存的大小。

在解决硬解析后，再次采集AWR报告，观察一下其中关于DataBuffer和SharePool的建议，看看内存是否合理，是否够用。

如果内存不够用，可以按照建议值增加其大小。

为了增加这两个组件的大小，应该先增加sga_target,然后再分别设置DataBuffer和SharePool的最小值：

Alter system set sga_target=XXXM Scope=Both

Alter system set db_cache_size=XXXM Scope=Both某地AWR报告分析.docx

Alter system set share_pool_size=XXXM Scope=Both

当然，前提是服务器有足够的物理内存用于分配。

在进行优化后，应该采集AWR报告，观察数据库吞吐量是否提高，之前的TOP5等待事件是否被消除。