1先看一张，描述awr和ash的一些基础信息复制代码
1 SQL> conn /as sysdba
2 Connected
3 SQL> @/rdbms/admin/awrrptsql
4
5 Current Instance
6 ~~~~~~~~~~~~~~~~
7
8 DB Id DB Name Inst Num Instance
9 ----------- ------------ -------- ------------10 3918594034 ORCL 1 orcl
11
12
13 Specify the Report Type
14 ~~~~~~~~~~~~~~~~~~~~~~~
15 Would you like an HTML report, or a plain text report
16 Enter 'html' for an HTML report, or 'text' for plain text17 Defaults to 'html'
18 Enter value for report_type: html
19
20 Type Specified: html
21
22
23 Instances in this Workload Repository schema24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~25
26 DB Id Inst Num DB Name Instance Host27 ------------ -------- ------------ ------------ ------------28 3918594034 1 ORCL orcl DCMSBDM
29
30 Using 3918594034 for database Id
31 Using 1 for instance number
32
33
34 Specify the number of days of snapshots to choose from35 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~36 Entering the number of days (n) will result in the most recent37 (n) days of snapshots being listed Pressing <return> without38 specifying a number lists all completed snapshots
39
40
41 Enter value for num_days: 2
42
43 Listing the last 2 days of Completed Snapshots44
45 Snap
46 Instance DB Name Snap Id Snap Started Level47 ------------ ------------ --------- ------------------ -----48 kobra KOBRA 1227 20 Aug 2012 00:00 149 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
58
59
60 Specify the Begin and End Snapshot Ids61 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~62 Enter value for begin_snap: 1227
63 Begin Snapshot Id specified: 1227
64
65 Enter value for end_snap: 1265
66 End Snapshot Id specified: 1265
67
68
69 Specify the Report Name
70 ~~~~~~~~~~~~~~~~~~~~~~~
71 The default report file name is awrrpt_1_1227_1265html To use this name,72 press <return> to continue, otherwise enter an alternative
73
74 Enter value for report_name:
75
76 Using the report name awrrpt_1_1227_1265html77
78 <html><head><title>AWR Report for DB: KOBRA, Inst: kobra, Snaps: 1227-1265</title>
79
80
81
82 End of Report
83 </body></html>
84 Report written to awrrpt_1_1227_1265html85
86 SQL> exit
复制代码
如何分析AWR
Automatic Workload Repository是10g引入的一个重要组件。在里面存贮着近期一段时间内，默认是7天，数据库活动状态的详细信息。
AWR报告是对AWR视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份AWR报告。
exec dbms_workload_repositorycreate_snapshot; running the specified workload
exec dbms_workload_repositorycreate_snapshot;@/rdbms/admin/awrrpt
通过AWR和AWR报告，DBA可以容易地获知最近数据库的活动状态，数据库的各种性能指标的变化趋势曲线，最近数据库可能存在的异常，分析数据库可能存在的性能瓶颈从而对数据库进行优化。
AWR报告所有的数据来源于AWR视图，即以DBA_HIST_开头的所有系统表，Database Reference有对所有这些系统表的描述，这应该是Oracle官方对AWR报告的官方注释了。
而对于如何有效地去分析AWR报告，这可能更需要DBA经验的日积月累。
AWR的前身是Statspack，Statspack在10g和11g中也有提供，同时和AWR一起做了同步更新，而且Statspack是公开源代码的，因此，关于Statspack的资料，还有Statspack的源代码，都是理解AWR的一个有用的辅助。
如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。
而细分起来，CPU可能指的是
OS级的User%, Sys%, Idle%
DB所占OS CPU资源的Busy%
DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然:
如何分析AWR - elliptic - 心事
OS级的%User为754，%Sys为28，%Idle为212，所以%Busy应该是788。
DB占了OS CPU资源的691，%Busy CPU则可以通过上面的数据得到：
%Busy CPU = %Total CPU/(%Busy) 100 = 691/788 100 = 8769，和报告的877相吻合。
如果是10g呢，则需要手工对Report里的一些数据进行计算了。
Host CPU的结果来源于DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second,也就是1/100秒)如何分析AWR - elliptic - 心事
这里，
%User = USER_TIME/(BUSY_TIME+IDLE_TIME)100 = 146355/(152946+41230)100 = 7537%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 = 24272 seconds当然，这正确无误。
至于DB对CPU的利用情况，这就涉及到10g新引入的一个关于时间统计的视图了， v$sys_time_model，简单而言，Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括:
1) background elapsed time
2) background cpu time
3) RMAN cpu time (backup/restore)
1) DB time
2) DB CPU
2) connection management call elapsed time2) sequence load elapsed time
2) sql execute elapsed time
2) parse time elapsed
3) hard parse elapsed time
4) hard parse (sharing criteria) elapsed time5) hard parse (bind mismatch) elapsed time3) failed parse elapsed time
4) failed parse (out of shared memory) elapsed time2) PL/SQL execution elapsed time
2) inbound PL/SQL rpc elapsed time
2) PL/SQL compilation elapsed time
2) Java execution elapsed time
2) repeated bind elapsed timea
我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。
这两个值在AWR里面也有记录:
image
Total DB CPU = DB CPU + background cpu time = 130589 + 3591 = 13418 seconds再除以总的 BUSY_TIME + IDLE_TIME
% Total CPU = 13418/194176 = 691%，这刚好与上面Report的值相吻合。
其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。
image
用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。
这里 53/8 = 6625 %
比691%稍小，说明DB在后台也消耗了大约3%的CPU，这是不是一个最简单的方法了呢？
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的描述:
image
这个系统的CPU个数是8，因此我们可以知道前台进程用了系统CPU的71/8=8875%。DB Time/s为117，可以看出这个系统是CPU非常繁忙的。里面CPU占了71，则其它前台等待事件占了117 – 71 = 46 Wait Time/s。DB Time 占 DB CPU的比重呢？ 71/117= 6068%Top 5 Timed Events，或许很多人都对它有所耳闻，按照CPU/等待事件占DB Time的比例大小，这里列出了Top 5。如果一个工作负载是CPU繁忙型的话，那么在这里应该可以看到 DB CPU的影子。
image
注意到，我们刚刚已经算出了DB CPU 的%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利用率 = DB CPU/(CPU_COUNTElapsed TIME)。
这个Top 5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用insert append的方式写入磁盘，同时，主要时间耗费在CPU的运算上。
上面提到，DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计：
image
DB CPU = 647465
DB TIME = 107112
FG Wait Time = 118263
明显的，DB CPU + FG Wait Time < DB Time，只占了715%其它的285%被消耗到哪里去了呢？这里其实又隐含着一个Oracle如何计算DB CPU和DB Time的问题。当CPU很忙时，如果系统里存在着很多进程，就会发生进程排队等待CPU的现象。在这样，DB TIME是把进程排队等待CPU的时间算在内的，而DB CPU是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time的一个重要原因。如果一个系统CPU不忙，这这两者应该就比较接近了。
不要忘了在这个例子中，这是一个CPU非常繁忙的系统，而715%就是一个信号，它提示着这个系统可能是一个CPU-Bound的系统。
除了DB CPU，DB Time，或许另一个比较常用的指标应该是IO的利用情况。关于IO的指标就比较多了，单单在Load Profile里面就有5个，在DB Time和DB CPU的下面：
image
这5个指标的值都来自v$systat视图，分别是：
Redo Size: ‘redo size’
Logical reads = ’session logical reads’ or (’db block gets’ + ‘consistent gets’)Blocks Changes = ‘db block changes’
Physical reads = ‘physical reads’
Physical writes = ‘physical writes’
具体指标的解释参考Database Reference
如何得到系统大致的MBPS呢？
MBPS= (Physical reads + Physical writes) Block_Size = (196,2714+20)81024/1024/1024 = 1533 MB/s更准确的MBPS可以从Instance Activity Stats部分获得。
image
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 redundancy，一份数据写了两遍的原因。
Load Profile剩下的部分主要是关于各种执行情况的统计，除了W/A MB processed来自v$pgastat（单位其实也是Byte，不是MB），其它数据都是来自于v$sysstat。
Blocks Changes: ‘db block changes’
User calls: ‘user calls’
Parses: ‘parse count (total)’
Hard parses: ‘parse count (hard)’
Logons: ‘logons cumulative’
Executes: ‘execute count’
Rollbacks: ‘user rollbacks’
Tranasactions: ‘user rollbacks’ + ‘user commits’
W/A MB processed: ‘bytes processed’
一般而言，Hard parses < Parses < Executes < User Calls。
AWR的一般性介绍我想差不多就这些了，其它部分的介绍借助于一些更具体的AWR报告进行分析可能会更加方便和清晰。
如果这个系列是按“总-分-总”组织的话，接下来的系列应该是进行“分”这一部分了。
构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行 *** 作，通过类似insert /+ append / into table select from external_table的方式进行加载。
数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。换句话说，如果连数据加载都出现IO瓶颈，这个系统的配置就说不过去了。
这个过程的AWR报告会是怎么样子的呢？
先做个一般的假定，从外部表加载数据到一个本地分区表。
Top 5 Timed Events类似下面：
image
如果去抓取这段时间DBA_HIST_ACTIVE_SESS_HISTORY的数据，并转换为图表的话，我们会得到更形象的Top 10 Wait Events
以上就是关于数据恢复课程全部的内容，包括:数据恢复课程、oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥、Oracle中获取执行计划的几种方法分析等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）