AWR报告中对各内存组件的Advisory.docx

DCS组需要进行内存调整，因此通过这一周的数据库运行，积累了一定的数据，我们只选Memory Advisory部分，来说下AWR部分中，Oracle自己对我们提出的内存调整的建议。这些建议是oracle通过自身设置一个模拟环境，把内存组建设置不同的大小的建议，对于这种改变造成的相关方面的性能影响进行估算，最后将这个估算清单提交给我们。这几部分并不能帮助我们直观的定位系统问题，但是它会给我们一些关于oracle内存大小的建议，所以我们应该关注一下这里，以便知道当前数据库在这方面的设置是否合理。可能因此各ORACLE和版本不同，AWR的样式不太一样，但主要的部分是差不多的，DCS PROD是11gr2，我们以此为例。而且AWR报告取的时间段为一周，而且AWR报告的原始数据在DB中也只能存一星期。我们从AWR报告的先后顺序说起。主要部分有：Buffer Pool AdvisoryPGA Memory AdvisoryShared Pool AdvisorySGA Target Advisory我们来看下各列的含义：Size for Est(M)Oracle估算Buffer pool的大小Size Factor估算值和实际值的一个比例，比如0.9就是估算值是实际大小的90%，1.0表示buffer pool的实际大小Buffers for Estimate估算的buffer的大小（数量）Est Phys Read Factor估算的物理读的影响因子，是估算物理读和实际物理读的一个比例，1.0表示实际的物理读Estimated Physical Reads估算的物理读次数我们首先找到目前的buffer pool值，即Size Factor是1.00的地方，1,152。我们随着Size Factor不断变大，来看下物理读（这是我们最关于的结果）的变化情况。当buffer pool变成现在的1.07-1.56倍的时候，物理读下降的明不明显，但增加为1.65倍时，开始有所降低，当增加为1.75倍，时，物理读将变为现在的38%。这将是一个可以考虑的平衡点。但再继续增加buffer pool时，物理读下降的并不明显，即收益不大，不予考虑。因此，若在server总内存充足的情况下，将buffer pool（隶属于sga）增加至2128m是一个不错的选择。我们来看下各列的含义：PGA Target Est (MB)PGA的估算大小Size Factr影响因子，作用和buffer pool相同W/A MB ProcessedOracle为了产生估算处理的数据量Estd Extra W/A MB处理数据中需要物理读写的数据量Estd PGA Cache Hit %估算的PGA命中率Estd PGA Overalloc Count需要在估算的PGA大小额外分配内存的次数由于此图过于炫富，无可参考性，即就算PGA变为现在的1/10，物理读也不会增加，没什么可比性，说明：这库在这周内太闲了。我们来看下DCS PROD之前的一个AWR情况：最初PGA只有200M，我即建议SYSTEM TEAM增加至400M+，为什么呢。我们注意到，亦以当时的200M为1.00的参数因子，当变成2倍的400M时，物理读从5537骤降至5，几个数量级之前的差距，因此多增加200M的内存，收益是非常大的。但是，从400M增加至500M或者是更大，物理读降低的可怜，但将付出更多的总内存，因此是不太划算的。当然，我们也需要有未雨绸缪的心态，可以考虑酌情添加，比如像现在的500M，就是一个比较适合的数值了。我们现在来看下对数据库性能最大的shared pool的情况，我们来看下各列的含义：Shared Pool Size(M)估算共享池的大小SP Size Factr估算共享池的影响因子Est LC Size (M)估算的库高速缓存占用的大小（LC，library cache）Est LC Mem Obj高速缓冲区命中的对象数Est LC Time Saved (s)需要额外将对象读入共享池的时间Est LC Time Saved Factr影响因子Est LC Load Time (s)分析所花费的时间Est LC Load Time Factr分析花费时间事件的影响因子Est LC Mem Obj Hits内存中对象被发现的次数不同与前2个的是，我们最关心的因子是Est LC Time Saved Factr，它表示每模拟一次sharedpool大小将对对象读入共享池的影响情况，当这个值变化很小或者不变的时候，增加shared pool就没有多大意义比如Est LC Time Saved Factr=1，随着内存的增大，它的值变化显得非常小，所以我们认为当前共享池大小事合适的。我们顺手瞄一眼4PL的情况：我们发现当shared pool从当时值的80%之后，Est LC Time Saved Factr即不再增加，因此是够用的。因此我取的都是一整个星期的情况，而且SGA都是自动的动态调整的，从连续几星期来看都是如此的话，说明。4PL还是蛮富有的。各列说明：SGA Target Size (M)估算SGA大小SGA Size FactorSGA大小的影响因子EstDB Time(s)估算的SGA大小计算出的DB TimeEst Physical Reads物理读次数SGA这部分比较简单，我们看到当前的SGA大小基本上是合适的，当影响因子从0.75到1时，物理读减少了很多，下面的影响程度就没有那么大了。当SYSTEM TEAM让我们提出自己内存的需求时，提供一段时间内（一般是一星期，而且AWR报告的原始数据也只能存一星期）Oracle的AWR报告，会是非常有力的证据。因此对于DCS PROD库的建议是，加大SGA至4G，并手工指定buffer pool在sga中大小不低于2G。当然，当时system temp已经跟我们说是sga会给我们5G，我们就心安理得的接受好了。你懂的。总体来说，DCS PROD这周是非常清闲的，为什么？我们回头看下AWR报告最开始的部分：它包含了数据和实例的一个基本信息，如果是一个rac结构，RAC选项为YES，最好对每个实例做性能分析。这部分是采集周期里系统的一个概述，要注意下面三个列的含义：1、 sessions表示采集是实例连接的会话数，这个数可以让我们了解数据库并发用户的大概情况。如果是新接手的数据库，对判断数据库的类型可以做参考2、 Cursors/Session，平均每个会话卡开的游标数。3、 DB Time 这个数值比较重要，它表示用户操作花费的时间，包括cpu和等待事件。有时候DB Time会比Elapsed时间要长。因为AWR是一个数据的合集，比如说1分钟内一个用户等待10秒钟，那么10个用户是300秒（5分钟）；cpu的时间也是一样一分钟之内，一个cpu处理30秒，那么4个cpu就是1.2分钟，8个就是2.4分钟，这些都以累计的方式记录在awr报告当中的。我们注意到，DB Time是要小于自然时间的，这说明。此库非常闲。因为此库为OLTP类型的库，我们再留意下2个值，Library Hit/Buffer Hit。即AWR报告的下一部分：除去Library Hit略低之外，整体的性能指标还是不错的。可能有的同事会问，execute to parse这里很低是不是数据库有问题了呢？不一定的。这不是绑定变量的问题。这个比例是由于太多的soft parse导致的，对于比如我们的web服务，这个值很小是正常的。因为用户要反复链接，每一次链接及时相同的sql，都会有一次soft parse。这个参数