AWR（Automatic Workload Repository）——分析（4）！

不一樣的天空w發表於2017-07-01

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：這個指標說明在當前的效能採集區間裡面，消耗的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
這一部分是表空間的I/O效能統計，這裡面的資料也是相對的。

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
這部分是檔案級別的I/O統計，和上一部分表空間的資訊一樣。


從下面這部分開始，會看到給出一些關於各個記憶體元件大小的建議。

這幾部分並不能幫組我們直觀的定位系統的效能，但是它給我們一些關於幾個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
這一部分是buffer pool的大小建議。

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記憶體大小的建議。

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整體效能的一個建議。

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
這兩部分是從物件角度來展現I/O的情況。分析這兩部分資訊，可以具體知道是哪些物件的訪問導致了I/O效能的下降，這些資訊對於我們最終定位和解決問題有一定幫助。


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報告裡面提供了非常豐富的內容，其它部分在這裡就不做介紹了！！！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31397003/viewspace-2141473/，如需轉載，請註明出處，否則將追究法律責任。

相關文章