ORACLEAWR报告生成和分.pdf

《ORACLEAWR报告生成和分.pdf》由会员分享，可在线阅读，更多相关《ORACLEAWR报告生成和分.pdf（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ORACLE AWR报告生成和分析Automatic Workload Repository是 10g引入的一个重要组件。在里面存贮着近期一段时间内，默认是7 天，数据库活动状态的详细信息。AWR报告是对 AWR视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份AWR报告。exec dbms_workload_repository.create_snapshot;.running the specified workload exec dbms_workload_repository.create_snapshot;?/rdbms/admin/awrrpt 通过 AWR和

2、AWR报告，DBA可以容易地获知最近数据库的活动状态，数据库的各种性能指标的变化趋势曲线，最近数据库可能存在的异常，分析数据库可能存在的性能瓶颈从而对数据库进行优化。AWR报告所有的数据来源于AWR视图，即以 DBA_HIST_ 开头的所有系统表，Database Reference 有对所有这些系统表的描述，这应该是 Oracle官方对 AWR报告的官方注释了。而对于如何有效地去分析AWR报告，这可能更需要DBA经验的日积月累。AWR的前身是 Statspack，Statspack在 10g 和 11g 中也有提供，同时和AWR一起做了同步更新，而且Statspack是公开源代码的，因此，关

3、于Statspack的资料，还有 Statspack的源代码，都是理解AWR的一个有用的辅助。如果关注数据库的性能，那么当拿到一份AWR 报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。而细分起来，CPU可能指的是OS级的 User%,Sys%,Idle%DB所占 OS CPU 资源的 Busy%DB CPU 又可以分为前台所消耗的CPU和后台所消耗的 CPU 如果数据库的版本是11g，那么很幸运的，这些信息在 AWR报告中一目了然：OS级的%User为 75.4，%Sys为 2.8，%Idle为 21.2，所以%Busy应该是 78.8。DB占了 OS

4、 CPU 资源的 69.1，%Busy CPU 则可以通过上面的数据得到：%Busy CPU=%Total CPU/(%Busy)*100=69.1/78.8*100=87.69，和报告的87.7 相吻合。如果是 10g呢，则需要手工对 Report 里的一些数据进行计算了。Host CPU的结果来源于DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second，也就是 1/100 秒)。这里，%User=USER_TIME/(BUSY_TIME+IDLE_TIME)*100=146355/(152946+41230)*100=75

5、.37%Sys=SYS_TIME/(BUSY_TIME+IDLE_TIME)*100%Idle=IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100 值得注意的，这里已经隐含着这个AWR报告所捕捉的两个snapshot 之间的时间长短了。有下面的公式BUSY_TIME+IDLE_TIME=ELAPSED_TIME*CPU_COUNT 正确的理解这个公式可以对系统CPU 资源的使用及其度量的方式有更深一步的理解。因此 ELAPSED_TIME=(152946+41230)/8/100=242.72 seconds。至于 DB对 CPU的利用情况，这就涉及到10g 新引入的一个关

6、于时间统计的视图了，v$sys_time_model，简单而言，Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括：background elapsed time background cpu time RMAN cpu time(backup/restore)DB time DB CPU connection management call elapsed time sequence load elapsed time sql execute elapsed time parse time elapsed hard parse elapsed time

7、 hard parse(sharing criteria)elapsed time hard parse(bind mismatch)elapsed time failed parse elapsed time failed parse(out of shared memory)elapsed time PL/SQL execution elapsed time inbound PL/SQL rpc elapsed time PL/SQL compilation elapsed time Java execution elapsed time repeated bind elapsed tim

8、e 我们这里关注的只有和CPU相关的两个:background cpu time 和 DB CPU。这两个值在 AWR里面也有记录:Total DB CPU=DB CPU+background cpu time=1305.89+35.91=1341.8 seconds，再除以总的BUSY_TIME+IDLE_TIME：%Total CPU=1341.8/1941.76=69.1%，这刚好与上面 Report 的值相吻合。其实，在 Load Profile部分，我们也可以看出 DB对系统 CPU的资源利用情况。用 DB CPU per Second 除以 CPU Count就可以得到 DB在前台

9、所消耗的 CPU%了。这里 5.3/8=66.25%，比69.1%稍小，说明 DB在后台也消耗了大约3%的CPU。DB CPU是一个用于衡量CPU的使用率的重要指标。假设系统有N 个 CPU，那么如果 CPU全忙的话，一秒钟内的DB CPU 就是 N 秒。如何去表征一个系统的繁忙程度呢？除了利用CPU进行计算外，数据库还会利用其它计算资源，如网络，硬盘，内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有M 个 session在运行，同一时刻，有的session可能在利用 CPU，有的 session可能在访问硬盘，那么，在一秒钟内，所有session的时间加起来就可以表征系统在这一

10、秒内的繁忙程度，一般的，这个和的最大值应该为 M。这其实就是 Oracle提供的另一个重要指标：DB time，它用以衡量前端进程所消耗的总时间。对除 CPU以后的计算资源的访问，Oracle用等待事件进行描述。同样地，和CPU可分为前台消耗 CPU和后台消耗 CPU一样，等待事件也可以分为前台等待事件和后台等待事件。DB Time一般的应该等于DB CPU+前台等待事件所消耗时间的总和。等待时间通过 v$system_event视图进行统计，DB Time和 DB CPU则是通过同一个视图，即 v$sys_time_model进行统计。Load Profile一节就有了对 DB Time的描

11、述：这个系统的CPU 个数是8，因此我们可以知道前台进程用了系统CPU 的7.1/8=88.75%。DB Time/s 为 11.7，可以看出这个系统是CPU非常繁忙的。里面CPU占了 7.1，则其它前台等待事件占了11.7 7.1=4.6 Wait Time/s。DB Time 占 DB CPU 的比重呢？7.1/11.7=60.68%Top 5 Timed Events，或许很多人都对它有所耳闻，按照CPU/等待事件占 DB Time的比例大小，这里列出了Top 5。如果一个工作负载是CPU繁忙型的话，那么在这里应该可以看到DB CPU 的影子。注意到，我们刚刚已经算出了DB CPU 的%

12、DB time，60%。其它的 external table read,direct path write,PX Deq:read credit,PX Deq:Slave Session Stats 这些就是占比重 40 的等待事件里的 Top 4了。回过头再再研究下这个Top 5 Timed Foreground Events，如果先不看Load Profile，你能说出这个一个CPU-Bound的工作负载吗？答案是否定的，要知道系统CPU的繁忙程序，还要知道这个AWR所基于两个 snapshot 的时间间隔，还要知道系统CPU的个数。要不，系统可以是一个很IDLE的系统呢。记住 CPU利用

13、率=DB CPU/(CPU_COUNT*Elapsed TIME)。这个 Top 5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用 insert append 的方式写入磁盘，同时，主要时间耗费在CPU的运算上。上面提到，DB Time 一般的应该等于 DB CPU+前台等待事件所消耗时间的总和。在下面有对这三个值的统计：DB CPU=6474.65 DB TIME=10711.2 FG Wait Time=1182.63 明显的，DB CPU+FG Wait Time DB Time，只占了 71.5%，其它的 28.5%被消耗到哪里去了呢？这里其实又隐含着一个Orac

14、le如何计算 DB CPU 和 DB Time的问题。当 CPU很忙时，如果系统里存在着很多进程，就会发生进程排队等待CPU的现象。在这样，DB TIME是把进程排队等待CPU的时间算在内的，而DB CPU是不包括这一部分时间。这是造成DB CPU+FG Wait Time DB Time的一个重要原因。如果一个系统CPU不忙，这这两者应该就比较接近了。不要忘了在这个例子中，这是一个CPU非常繁忙的系统，而71.5%就是一个信号，它提示着这个系统可能是一个CPU-Bound的系统。除了 DB CPU，DB Time，或许另一个比较常用的指标应该是IO的利用情况。关于 IO 的指标就比较多了，单

15、单在 Load Profile里面就有 5 个，在 DB Time和 DB CPU的下面：这 5 个指标的值都来自v$systat视图，分别是：Redo Size:redo sizeLogical reads=session logical reads or(db block gets+consistent gets)Blocks Changes=db block changesPhysical reads=physical readsPhysical writes=physical writes如何得到系统大致的MBPS呢？MBPS=(Physical reads+Physical writ

16、es)*Block_Size=(196,271.4+2.0)*8*1024/1024/1024=1533 MB/s 更准确的 MBPS可以从 Instance Activity Stats部分获得。physical IO disk bytes=physical read total bytes+physical write total bytes 值得注意的是这里 physical write total bytes 大致是 physical write bytes的两倍。这应该是 physical write total bytes 统计的是磁盘的 IO，而这里，我们做了ASM，normal

17、 redundancy，一份数据写了两遍的原因。Load Profile 剩下的部分主要是关于各种执行情况的统计，除了W/A MB processed来自 v$pgastat（单位其实也是Byte，不是 MB），其它数据都是来自于v$sysstat。Blocks Changes:db block changesUser calls:user callsParses:parse count(total)Hard parses:parse count(hard)Logons:logons cumulativeExecutes:execute countRollbacks:user rollback

18、sTranasactions:user rollbacks+user commitsW/A MB processed:bytes processed一般而言，Hard parses Parses Executes User Calls。AWR的一般性介绍我想差不多就这些了，其它部分的介绍借助于一些更具体的 AWR报告进行分析可能会更加方便和清晰。如果这个系列是按“总-分-总”组织的话，接下来的系列应该是进行“分”这一部分了。构建 DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似 inser

19、t/*+append*/into table select from external_table 的方式进行加载。数据加载是一个 CPU-Bound的过程，不过是通过什么工具，external table 也好，sqlldr 也好，imp 也好，impdp 也好。换句话说，如果连数据加载都出现I/O瓶颈，这个系统的配置就说不过去了。这个过程的 AWR报告会是怎么样子的呢？先做个一般的假定，从外部表加载数据到一个本地分区表。Top 5 Timed Events 类似下面：如果去抓取这段时间DBA_HIST_ACTIVE_SESS_HISTORY的数据，并转换为图表的话，我们会得到更形象的Top

20、 10 Wait Events。enq:HV contention 是什么东西呢？在 11.2 以前，对于分区表的 parallel direct-path load，Oracle采用的是 brokered load 的方式，即所有的PX Slaves 共享对每个分区的high water mark 的访问，通过轮流持有 high water mark 实现对每个 segment 添加新的 blocks。这种方法对于充分利用 extent 的空间是有帮助的，不过带来的问题就是对high water mark 的竞争，也就是这里的 enq:HV contention。在执行计划中，这以 RAND

21、OM LOCAL 标记。下面是一个例子：一个好消息是，11.2 引入了一种新的方式，叫做 PKEY distribution。在这种方式下，一个特定的分区只交给一个或多个特定的PX slave负责，这种方式不仅减少了对 high water mark 的争用，而且可以实现partition 内更好的压缩率。现在探讨另一个对系统CPU进行度量的指标:CPU used by this session。他刚好有一份AWR 报告，在这份报告里，出现了严重的CPU used by this session和 DB CPU不一致的现象。下面是这份报告的一些片断：再做进一步的归纳：OS Busy%=1821

22、080/(1821080+5384293)=25%Inst CPU%(using DB CPU)=8934.22*100/(1821080+5384293)=12%Inst CPU%(using CPU used by this session)=418035/(1821080+5384293)=6%用 CPU used by this session 计算出的 CPU利用率竟然只是用 DB CPU 计算出来的利用率的一半！“prior to 10g Oracle usually updated time figures at the end of each database call;but

23、 from 10g there are some views where time is updated more regularly.The“DB CPU”from v$sess_time_model increases every six seconds,while the“CPU used by this session”from v$sesstat changes only at the end of the test.”如何验证这一点呢？在浏览这份报告的TOP SQL 时，我们发现了下面的现象：这是从 SQL ordered by Elapsed Time 截取出来的 Top 3 S

24、QL。TOP 1的 SQL用了DB Time的 30.10%，用了 2517s 的 CPU Time。但请注意它的 Executions的值却为0。也就是说，这里的CPU Time是还没有被计算入 CPU used by this session 这个指标里面的。我们再把 2517s加回来，看出误差缩小多少:(251700+418035)/(1821080+5384293)=9%这时和用 DB CPU计算出来的 12%还是有 1/4 的差距。从这个例子可以看出，用 DB CPU度量还是比用 CPU used by this session 来得准确的。特别在有大查询在跑的过程中抓的AWR，这个误差很有可能会被放大。