AWR（Automatic Workload Repository）——分析（4）！
Instance Activity Stats
| Statistic | Total | per Second | per Trns |
|---|---|---|---|
| CPU used by this session | 99,100 | 102.31 | 91.84 |
。。。 。。。
这部分是实例的信息统计，项目非常多，我值重点讨论上面这个事件。
CPU used by this session：这个指标说明在当前的性能采集区间里面，Oracle消耗的cpu单位，一个cpu单位是1/100秒。
假设我们现在系统是6颗cpu的服务器，那么每颗cpu消耗的cpu单位就是102/6=17个cpu单位。
在一秒钟内，每个cpu处理的时间就是17/100=0.17秒。从这里可以判断数据库的cpu资源丰富，远没有出现瓶颈。
Tablespace IO Stats
- ordered by IOs (Reads + Writes) desc
| Tablespace | Reads | Av Reads/s | Av Rd(ms) | Av Blks/Rd | Writes | Av Writes/s | Buffer Waits | Av Buf Wt(ms) |
|---|---|---|---|---|---|---|---|---|
| SYSAUX | 227 | 0 | 9.96 | 1.01 | 420 | 0 | 0 | 0.00 |
| UNDOTBS1 | 5 | 0 | 4.00 | 1.00 | 217 | 0 | 1 | 10.00 |
| SYSTEM | 120 | 0 | 11.67 | 1.75 | 74 | 0 | 0 | 0.00 |
Reads：发生了多少次物理读
Av Reads/s ：每秒钟物理读的次数
Av Rd(ms) ：平均一次物理读的时间（毫秒）
Av Blks/Rd ：每次读了多少个数据块
Writes ：发生了多少次写
Av Writes/s ：每秒钟写的次数
Buffer Waits ：获取内存数据块等待的次数
Av Buf Wt(ms) ：获取内存数据块平均等待时间
File IO Stats
- ordered by Tablespace, File
| Tablespace | Filename | Reads | Av Reads/s | Av Rd(ms) | Av Blks/Rd | Writes | Av Writes/s | Buffer Waits | Av Buf Wt(ms) |
|---|---|---|---|---|---|---|---|---|---|
| SYSAUX | /u01/app/oracle/oradata/orcl/sysaux01.dbf | 227 | 0 | 9.96 | 1.01 | 420 | 0 | 0 | 0.00 |
| SYSTEM | /u01/app/oracle/oradata/orcl/system01.dbf | 120 | 0 | 11.67 | 1.75 | 74 | 0 | 0 | 0.00 |
| UNDOTBS1 | /u01/app/oracle/oradata/orcl/undotbs01.dbf | 5 | 0 | 4.00 | 1.00 | 217 | 0 | 1 | 10.00 |
从下面这部分开始，会看到oracle给出一些关于各个内存组件大小的建议。
这几部分并不能帮组我们直观的定位系统的性能，但是它给我们一些关于几个Oracle内存组件大小的建议，所以我们应该关注一下这里，以便于知道当前数据库在这方面的设置是否合理。Buffer Pool Advisory
- Only rows with estimated physical reads >0 are displayed
- ordered by Block Size, Buffers For Estimate
| P | Size for Est (M) | Size Factor | Buffers for Estimate | Est Phys Read Factor | Estimated Physical Reads |
|---|---|---|---|---|---|
| D | 96 | 0.10 | 11,502 | 1.01 | 9,280,242,678 |
| D | 192 | 0.20 | 23,004 | 1.01 | 9,221,206,840 |
| D | 288 | 0.30 | 34,506 | 1.00 | 9,203,382,424 |
| D | 384 | 0.40 | 46,008 | 1.00 | 9,187,795,751 |
| D | 480 | 0.50 | 57,510 | 1.00 | 9,173,359,689 |
| D | 576 | 0.60 | 69,012 | 1.00 | 9,170,239,226 |
| D | 672 | 0.70 | 80,514 | 1.00 | 9,167,537,392 |
| D | 768 | 0.80 | 92,016 | 1.00 | 9,165,125,531 |
| D | 864 | 0.90 | 103,518 | 1.00 | 9,162,962,005 |
| D | 960 | 1.00 | 115,020 | 1.00 | 9,160,956,280 |
| D | 1,056 | 1.10 | 126,522 | 1.00 | 9,159,872,178 |
| D | 1,152 | 1.20 | 138,024 | 1.00 | 9,158,692,041 |
| D | 1,248 | 1.30 | 149,526 | 1.00 | 9,157,439,260 |
| D | 1,344 | 1.40 | 161,028 | 1.00 | 9,156,077,677 |
| D | 1,440 | 1.50 | 172,530 | 1.00 | 9,154,595,433 |
| D | 1,536 | 1.60 | 184,032 | 1.00 | 9,141,375,909 |
| D | 1,632 | 1.70 | 195,534 | 1.00 | 9,117,577,424 |
| D | 1,728 | 1.80 | 207,036 | 0.99 | 9,093,764,198 |
| D | 1,824 | 1.90 | 218,538 | 0.99 | 9,069,947,117 |
| D | 1,920 | 2.00 | 230,040 | 0.79 | 7,195,790,859 |
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的大小为960MB（Size
Factor=1.0），此时发出的物理读次数为9,160,956,280次，当Oracle尝试增大buffer
pool到原来的1.1倍大小时（Size
Factor=1.1），物理读降低到9,159,872,178，物理读降低了9,160,956,280-9,159,872,178=1084102次。如果我们继续增加buffer
pool的大小到原来的2倍时，物理读降低为7,195,790,859次，降低了9,160,956,280-7,195,790,859=1965165421次。可以发现尽管我们将buffer
pool的大小翻了一倍，物理读的下降程度是有限的，但我们付出的代价却是非常大的。所以我们不能一味的通过增加内存来减少物理读，需要找到一个最经济，效率又高的点，这就是Oracle建议器的目的。实际上，从上面可以看出这个系统目前还是非常闲的，buffer
pool稍微大一点，和小一点对物理读的影响并不会非常大。
PGA Memory Advisory
- When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0
| PGA Target Est (MB) | Size Factr | W/A MB Processed | Estd Extra W/A MB Read/ Written to Disk | Estd PGA Cache Hit % | Estd PGA Overalloc Count |
|---|---|---|---|---|---|
| 610 | 0.13 | 548,398.44 | 284,625.95 | 66.00 | 303 |
| 1,220 | 0.25 | 548,398.44 | 275,104.64 | 67.00 | 286 |
| 2,440 | 0.50 | 548,398.44 | 263,712.09 | 68.00 | 176 |
| 3,659 | 0.75 | 548,398.44 | 229,058.85 | 71.00 | 142 |
| 4,879 | 1.00 | 548,398.44 | 27,379.49 | 95.00 | 0 |
| 5,855 | 1.20 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 6,831 | 1.40 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 7,806 | 1.60 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 8,782 | 1.80 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 9,758 | 2.00 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 14,637 | 3.00 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 19,516 | 4.00 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 29,274 | 6.00 | 548,398.44 | 25,113.76 | 96.00 | 0 |
| 39,032 | 8.00 | 548,398.44 | 25,113.76 | 96.00 | 0 |
PGA Target Est (MB) ：PGA的估算大小
Size Factr ：影响因子，作用和buffer pool相同
W/A MB Processed ：Oracle为了产生估算处理的数据量
Estd Extra W/A MB Read/ Written to Disk ：处理数据中需要物理读写的数据量
Estd PGA Cache Hit % ：估算的PGA命中率
Estd PGA Overalloc Count ：需要在估算的PGA大小下额外分配的内存次数
这一部分我们要判断两个点，第一个点就是Oracle估算的PGA大小不会导致额外分配内存，在上面的表中就是Size
Factor=1.0时PGA的大小；第二个点是物理读写的值不在增加，在这里的Size
Factor=1.2的时候，如果要这两个条件满足，我们需要取Size
Factor=1.2时的PGA大小，即5855MB，即如果要达到PGA性能最好，应该将pga_aggregate_target设置为5855MB，这个值固然比前面的值性能要好，但是我们需要考虑实际内存情况。
Shared Pool Advisory
- SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor
- Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid.
| Shared Pool Size(M) | SP Size Factr | Est LC Size (M) | 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 (K) |
|---|---|---|---|---|---|---|---|---|
| 320 | 0.63 | 69 | 7,243 | 2,390,521 | 1.00 | 8,187 | 1.34 | 343,271 |
| 384 | 0.75 | 131 | 13,655 | 2,391,420 | 1.00 | 7,288 | 1.19 | 343,453 |
| 448 | 0.88 | 193 | 19,589 | 2,392,063 | 1.00 | 6,645 | 1.08 | 343,577 |
| 512 | 1.00 | 256 | 26,030 | 2,392,577 | 1.00 | 6,131 | 1.00 | 343,676 |
| 576 | 1.13 | 319 | 32,539 | 2,393,019 | 1.00 | 5,689 | 0.93 | 343,756 |
| 640 | 1.25 | 382 | 39,067 | 2,393,372 | 1.00 | 5,336 | 0.87 | 343,822 |
| 704 | 1.38 | 445 | 44,250 | 2,393,667 | 1.00 | 5,041 | 0.82 | 343,875 |
| 768 | 1.50 | 508 | 50,055 | 2,393,906 | 1.00 | 4,802 | 0.78 | 343,919 |
| 832 | 1.63 | 571 | 56,557 | 2,394,100 | 1.00 | 4,608 | 0.75 | 343,955 |
| 896 | 1.75 | 634 | 63,271 | 2,394,256 | 1.00 | 4,452 | 0.73 | 343,984 |
| 960 | 1.88 | 697 | 69,808 | 2,394,386 | 1.00 | 4,322 | 0.70 | 344,008 |
| 1,024 | 2.00 | 760 | 76,190 | 2,394,490 | 1.00 | 4,218 | 0.69 | 344,027 |
Shared Pool Size(M) ：估算的共享池大小
SP Size Factr ：共享池大小的影响因子
Est LC Size (M) ：估算的库高速缓存占用的大小（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 (K) ：内存中对象被发现的次数
我们看这个列表时，主要考虑这一列Est LC Time Saved Factr，它表示每一个模拟的Shared pool大小对重新将对象读入共享池的影响情况。当这个值变化很小，或者不变的时候，增加Shared pool大小就没有太大的意义！
SGA Target Advisory
| SGA Target Size (M) | SGA Size Factor | Est DB Time (s) | Est Physical Reads |
|---|---|---|---|
| 768 | 0.50 | 4,683,898 | 9,187,523,012 |
| 1,152 | 0.75 | 4,674,557 | 9,165,536,717 |
| 1,536 | 1.00 | 4,670,820 | 9,160,956,239 |
| 1,920 | 1.25 | 4,663,814 | 9,141,718,231 |
| 2,304 | 1.50 | 4,296,220 | 7,195,931,126 |
| 2,688 | 1.75 | 4,293,418 | 7,195,931,126 |
| 3,072 | 2.00 | 4,292,951 | 7,195,931,126 |
SGA Target Size (M) ：估算的SGA大小
SGA Size Factor ：SGA大小的影响因子
Est DB Time (s) ：估算的SGA大小计算出的DB Time
Est Physical Reads ：物理读次数
从上面的列表可以看见当影响因子变为SGA Size Factor=1.5倍的时候，物理读的次数下降还是比较客观的，但是内存是否充足呢！如果充足的话可以将SGA调整为2304MB。
Segments by Logical Reads
- Total Logical Reads: 3,662,795
- Captured Segments account for 89.9% of Total
| Owner | Tablespace Name | Object Name | Subobject Name | Obj. Type | Logical Reads | %Total |
|---|---|---|---|---|---|---|
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_SMSEND | TABLE | 1,818,848 | 49.66 | |
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_ORDER_INFO | TABLE | 186,880 | 5.10 | |
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_ORD_AUTO_NOTIFY | TABLE | 159,648 | 4.36 | |
| SYS | SYSTEM | I_OBJAUTH1 | INDEX | 138,272 | 3.78 | |
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_USERINFO | TABLE | 111,616 | 3.05 |
Segments by Physical Reads
- Total Physical Reads: 96,430
- Captured Segments account for 99.8% of Total
| Owner | Tablespace Name | Object Name | Subobject Name | Obj. Type | Physical Reads | %Total |
|---|---|---|---|---|---|---|
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_USERINFO | TABLE | 70,932 | 73.56 | |
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_SMSEND | TABLE | 21,318 | 22.11 | |
| UNIPAYUSER | CUCPAYPAYLAR | UK_BINDAGR | INDEX | 1,751 | 1.82 | |
| UNIPAYUSER | CUCPAYPAYLAR | UK_USR_MBLBIND | INDEX | 673 | 0.70 | |
| UNIPAYUSER | CUCPAYPAYLAR | T_PAY_MERBINDAGR | TABLE | 500 | 0.52 |
Segments by Buffer Busy Waits
- % of Capture shows % of Buffer Busy Waits for each top segment compared
- with total Buffer Busy Waits for all segments captured by the Snapshot
| Owner | Tablespace Name | Object Name | Subobject Name | Obj. Type | Buffer Busy Waits | % of Capture |
|---|---|---|---|---|---|---|
| UNIPAYUSER | CUCPAYPAYLAR | PK_T_MAN_JOURNAL | INDEX | 2 | 100.00 |
AWR报告里面提供了非常丰富的内容，其它部分在这里就不做介绍了！！！