awr报告基础之获取
来源 : http://blog.chinaunix.net/uid-643886-id-3568040.html
有些时候，我们需要分析占用资源比较大的sql的执行计划，也需要将sql的执行计划以报告的形式反馈给客户，由于AWR报告里的SQL通常都是些变量，因此以命令行方式生成sql的执行计划就很麻烦，而且也不美观，利用awrsqrpt.sql脚本就很方便。
生成HTML的执行计划很简单，如果是生成本地数据库的sql执行计划，执行awrsqrpt.sql就可以，但是如果需要生成由AWR迁移到本地数据库的分析数据，就需要使用awrsqrpi.sql。
SQL> @?/rdbms/admin/awrsqrpi
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
输入 report_type 的值: html
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 1520519778 1 STREAM stream STREAM
2400249746 1 CNDERPDB cnderpdb1 p5a1
2400249746 2 CNDERPDB cnderpdb2 p5b1
输入 dbid 的值: 2400249746 --输入要生成执行计划的数据库ID
Using 2400249746 for database Id
输入 inst_num 的值: 1 --输入节点号
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
输入 num_days 的值: 7
Listing the last 7 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
cnderpdb1 CNDERPDB 50063 16 6月 2011 08:00 1
50064 16 6月 2011 09:00 1
50065 16 6月 2011 10:00 1
50066 16 6月 2011 11:00 1
50067 16 6月 2011 12:00 1
... ...
50206 22 6月 2011 07:00 1
50207 22 6月 2011 08:00 1
50208 22 6月 2011 09:00 1
50209 22 6月 2011 10:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值: 50063 --输入开始快照号
Begin Snapshot Id specified: 50063
输入 end_snap 的值: 50209 --输入结束快照号
End Snapshot Id specified: 50209
Specify the SQL Id
~~~~~~~~~~~~~~~~~~
输入 sql_id 的值: 8hm5s0k011450 --在AWR报告中看到的占用资源较大的SQL ID
SQL ID specified: 8hm5s0k011450
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrsqlrpt_1_50063_50209.html. To use this name,
press <return> to continue, otherwise enter an alternative.
输入 report_name 的值: d:\stream.html --保存路径和名字
Using the report name d:\stream.html
Report written to d:\stream.html
SQL>
之后打开D盘下的stream.html就可以很直观的看到SQL_ID为8hm5s0k011450的执行计划
| Stat Name | Statement Total | Per Execution | % Snap Total |
|---|---|---|---|
| Elapsed Time (ms) | 18,121,198 | 4.89 | 3.20 |
| CPU Time (ms) | 17,874,450 | 4.82 | 3.33 |
| Executions | 3,707,839 | ||
| Buffer Gets | 404,447,392 | 109.08 | 3.85 |
| Disk Reads | 0 | 0.00 | 0.00 |
| Parse Calls | 6 | 0.00 | 0.00 |
| Rows | 9,831,284 | 2.65 | |
| User I/O Wait Time (ms) | 0 | ||
| Cluster Wait Time (ms) | 0 | ||
| Application Wait Time (ms) | 0 | ||
| Concurrency Wait Time (ms) | 0 | ||
| Invalidations | 0 | ||
| Version Count | 38 | ||
| Sharable Mem(KB) | 713 |
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
|---|---|---|---|---|---|---|
| 0 | SELECT STATEMENT | 3 (100) | ||||
| 1 | FOR UPDATE | |||||
| 2 | SORT ORDER BY | 1 | 32 | 3 (34) | 00:00:01 | |
| 3 | TABLE ACCESS FULL | TEMPSK | 1 | 32 | 2 (0) | 00:00:01 |
AWR中的一些参数简介：
来源 ：http://www.cnblogs.com/david-zhang-index/archive/2012/08/21/2649252.html
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 �C 进程消耗时间分析
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 �C 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的影子。
