11g awr oracle 系列_【原】oracle11G AWR使用及分析

最新推荐文章于 2024-06-18 02:32:04 发布

NetNinja

最新推荐文章于 2024-06-18 02:32:04 发布

阅读量241

点赞数

文章标签： 11g awr oracle 系列

本文链接：https://blog.csdn.net/weixin_31518415/article/details/112827541

版权

作者：david_zhang@sh 【转载时请以超链接形式标明文章】

链接：http://www.cnblogs.com/david-zhang-index/archive/2012/08/21/2649252.html

1.先看一张图片，描述awr和ash的一些基础信息

1 SQL> conn /assysdba2 Connected.3 SQL> @?/rdbms/admin/awrrpt.sql4

5 CurrentInstance6 ~~~~~~~~~~~~~~~~

8 DB Id DB Name Inst Num Instance9 ----------- ------------ -------- ------------

10 3918594034 ORCL 1orcl11

13 Specify the Report Type14 ~~~~~~~~~~~~~~~~~~~~~~~

15 Would you like an HTML report, or a plain textreport?16 Enter 'html' for an HTML report, or 'text' for plain text

17 Defaults to 'html'

18 Enter value forreport_type: html19

20 Type Specified: html21

23 Instances in this Workload Repository schema

24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

26 DB Id Inst Num DB Name Instance Host27 ------------ -------- ------------ ------------ ------------

28 * 3918594034 1ORCL orcl DCMSBDM29

30 Using 3918594034 for databaseId31 Using 1 for instance number

34 Specify the number of days of snapshots to choose from

35 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

36 Entering the number of days (n) will result inthe most recent37 (n) days of snapshots being listed. Pressing without38 specifying a number lists allcompleted snapshots.39

41 Enter value for num_days: 2

43 Listing the last 2 days ofCompleted Snapshots44

45 Snap46 Instance DB Name Snap Id Snap Started Level

47 ------------ ------------ --------- ------------------ -----

48 kobra KOBRA 1227 20 Aug 2012 00:00 1

49 1228 20 Aug 2012 01:00 1

50 1229 20 Aug 2012 02:00 1

51 1230 20 Aug 2012 03:00 1

52 1231 20 Aug 2012 04:00 1

53 ...54 1263 21 Aug 2012 12:00 1

55 1264 21 Aug 2012 13:00 1

56 1265 21 Aug 2012 14:00 1

57 1266 21 Aug 2012 15:00 1

60 Specify the Begin and EndSnapshot Ids61 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

62 Enter value for begin_snap: 1227

63 Begin Snapshot Id specified: 1227

65 Enter value for end_snap: 1265

66 End Snapshot Id specified: 1265

69 Specify the Report Name70 ~~~~~~~~~~~~~~~~~~~~~~~

71 The default report file name is awrrpt_1_1227_1265.html. To usethis name,72 press to continue, otherwise enter an alternative.73

74 Enter value forreport_name:75

76 Using the report name awrrpt_1_1227_1265.html77

AWR Report for DB: KOBRA, Inst: kobra, Snaps: 1227-1265

80 ...81

82 End ofReport83

84 Report written toawrrpt_1_1227_1265.html85

86 SQL> exit

2.AWR报告分析

2.1CPU负载分析

如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。而细分起来，CPU可能指的是：

1. OS级的User%，Sys%， Idle%

2. DB所占OS CPU资源的Busy%

3. DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU

如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然：

分析上面的图片，我们可以得出下面的结论：

OS级的User%，Sys%，Idle%：

OS级的%User为3.4，%Sys为0.4，%Idle为96.1，所以%Busy应该是100-96.1=3.9

DB所占OS CPU资源的Busy%：

DB占了OS CPU资源的3.7，%Busy CPU则可以通过上面的数据得到： %Busy CPU = %Total CPU/(%Busy) * 100 =3.7/3.9 * 100 = 94.87，应该和报告的95.3相吻合，这里有出入，我也不知道原因。

Host CPU的结果来源于DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second,也就是1/100秒)

%User = USER_TIME/ (BUSY_TIME+IDLE_TIME)*100 = 1,850,185/ (2,147,757+52,550,299)*100 = 3.38

%Sys = SYS_TIME/ (BUSY_TIME+IDLE_TIME)*100=234,229/ (2,147,757+52,550,299)*100=0.4

%Idle = IDLE_TIME/ (BUSY_TIME+IDLE_TIME)*100=52,550,299/ (2,147,757+52,550,299)*100=96.1

值得注意的，这里已经隐含着这个AWR报告所捕捉的两个Snapshot之间的时间长短了。有下面的公式：

BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

注意：正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。

因此ELAPSED_TIME = (2,147,757+52,550,299)/6/100 = 91163.42 seconds

Total DB CPU = DB CPU + Background CPU time = 20,108.16 + 357.62 = 20465.78 centi seconds

Total DB CPU除以总的 BUSY_TIME + IDLE_TIME可得出% Total CPU

% Total CPU = 20465.78/54698056 =3.7%，这刚好与上面Report的值相吻合。

其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。

用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。这里 0.2/6 = 3.3 %比3.7%稍小，说明DB在后台也消耗了大约0.4%的CPU，这是不是一个最简单的方法了呢？

3 DB Time – 进程消耗时间分析

DB CPU是一个用于衡量CPU的使用率的重要指标。假设系统有N个CPU，那么如果CPU全部处于繁忙状态的话，一秒钟内的DB CPU就是N秒。

如何去表征一个系统的繁忙程度呢？除了利用CPU进行计算外，数据库还会利用其它计算资源，如网络、硬盘、内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有M个Session在运行，同一时刻，有的Session可能在利用CPU，有的Session可能在访问硬盘，那么，在一秒钟内，所有Session的时间加起来就可以表征系统在这一秒内的繁忙程度，一般的，这个和的最大值应该为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的描述：

这个系统的CPU个数是6，因此我们可以知道前台进程用了系统CPU的0.2/6=3.3%。DB Time/s为0.2，可以看出这个系统是CPU不繁忙的。里面CPU占了0.2，则其它前台等待事件占了0.2 – 0.2 = 0 Wait Time/s。DB CPU占DB Time的比重呢？ 0.2/0.2= 100%

Top 5 Timed Events，或许很多人都对它有所耳闻，按照CPU/等待事件占DB Time的比例大小，这里列出了Top 5。如果一个工作负载是CPU繁忙型的话，那么在这里应该可以看到 DB CPU的影子。