1.分析群共享中發布的awr報告分析_作業.zip中的awr報告，貼出你認為能夠支持自己觀點的AWR報告中相應的部分，
并給出分析說明，最后給出AWR的分析結論。<br>
2.產生一個ASH報告，并進行分析，給出最后的結論。<br>
3.分析說明ASH和AWR報告的使用場景。<br>

=====================================================================================================

1.分析群共享中發布的awr報告分析_作業.zip中的awr報告，貼出你認為能夠支持自己觀點的AWR報告中相應的部分，
并給出分析說明，最后給出AWR的分析結論。<br>


答：


DB Name?? ?DB Id?? ?Instance?? ?Inst num?? ?Startup Time?? ?Release?? ?RAC
EMSTA?? ?433507400?? ?emsta2?? ?2?? ?14-Aug-12 22:08?? ?11.2.0.2.0?? ?YES

Host Name?? ?Platform?? ?CPUs?? ?Cores?? ?Sockets?? ?Memory (GB)
emsta2?? ?Solaris[tm] OE (64-bit)?? ?64?? ?32?? ?8?? ?128.00

Snap Id?? ?Snap Time?? ?Sessions?? ?Cursors/Session
Begin Snap:?? ?6023?? ?07-Sep-12 14:00:09?? ?1363?? ?3.0
End Snap:?? ?6026?? ?07-Sep-12 17:00:06?? ?1378?? ?3.0
Elapsed:?? ? ?? ?179.94 (mins)?? ? ?? ?
DB Time:?? ? ?? ?136.61 (mins)?? ? ?? ?

AWR 報表前面可以看出，這是一個RAC 環境，數據庫名稱： emsta 節點為：emsta1,emsta2
版本號： 11.2.0.2.0
操作系統： 64位 solaris,
CPU: 物理：64顆 （32*2 雙核）
MEM: 128G


?? ?Snap Id?? ?Snap Time?? ?Sessions?? ?Cursors/Session
Begin Snap:?? ?6023?? ?07-Sep-12 14:00:09?? ?1788?? ?2.8
End Snap:?? ?6026?? ?07-Sep-12 17:00:06?? ?1793?? ?2.9
Elapsed:?? ? ?? ?179.94 (mins)?? ? ?? ?
DB Time:?? ? ?? ?79.25 (mins)?? ? ?? ?

報表統計開始日期：07-Sep-12 14:00:09 結束日期07-Sep-12 17:00:06
開始SNAP 6023,結束SNAP: 6026;
EMSTA1 節點的會話數從： 1788 到1793，
EMSTA2 節點的會話數從： 1363 到1378，



EMSTA1 節點 Cache Sizes

?? ?Begin?? ?End?? ??? ?
Buffer Cache:?? ?15,360M?? ?15,360M?? ?Std Block Size:?? ?8K
Shared Pool Size:?? ?6,272M?? ?6,272M?? ?Log Buffer:?? ?111,456K

數據庫緩沖區15,360M ?
共享池 6,272M ?
redo log 緩沖區 111,456K
塊大小：8K





EMSTA2 節點 Cache Sizes

?? ?Begin?? ?End?? ??? ?
Buffer Cache:?? ?13,696M?? ?13,696M?? ?Std Block Size:?? ?8K
Shared Pool Size:?? ?6,144M?? ?6,144M?? ?Log Buffer:?? ?111,456K

數據庫緩沖區13596 M ?
共享池6144M? ?
redo log 緩沖區 111.456M
塊大小：8K


EMSTA1 節點 Load Profile

?? ?Per Second?? ?Per Transaction?? ?Per Exec?? ?Per Call
DB Time(s):?? ?0.4?? ?0.3?? ?0.01?? ?0.00
DB CPU(s):?? ?0.4?? ?0.2?? ?0.01?? ?0.00
Redo size:?? ?15,275.9?? ?8,983.0?? ? ?? ?
Logical reads:?? ?13,716.1?? ?8,065.8?? ? ?? ?
Block changes:?? ?79.2?? ?46.6?? ? ?? ?
Physical reads:?? ?365.3?? ?214.8?? ? ?? ?
Physical writes:?? ?4.5?? ?2.7?? ? ?? ?
User calls:?? ?232.7?? ?136.8?? ? ?? ?
Parses:?? ?11.4?? ?6.7?? ? ?? ?
Hard parses:?? ?0.3?? ?0.2?? ? ?? ?
W/A MB processed:?? ?2.7?? ?1.6?? ? ?? ?
Logons:?? ?0.0?? ?0.0?? ? ?? ?
Executes:?? ?54.3?? ?32.0?? ? ?? ?
Rollbacks:?? ?0.0?? ?0.0?? ? ?? ?
Transactions:?? ?1.7?? ? ?? ? ?? ?

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:?? ?100.00?? ?Redo NoWait %:?? ?100.00
Buffer Hit %:?? ?99.68?? ?In-memory Sort %:?? ?100.00
Library Hit %:?? ?99.36?? ?Soft Parse %:?? ?97.68
Execute to Parse %:?? ?79.06?? ?Latch Hit %:?? ?99.96
Parse CPU to Parse Elapsd %:?? ?90.29?? ?% Non-Parse CPU:?? ?99.46

Shared Pool Statistics



EMSTA2 節點 Load Profile


?? ?Per Second?? ?Per Transaction?? ?Per Exec?? ?Per Call
DB Time(s):?? ?0.8?? ?0.1?? ?0.00?? ?0.00
DB CPU(s):?? ?0.4?? ?0.1?? ?0.00?? ?0.00
Redo size:?? ?102,788.5?? ?11,594.5?? ? ?? ?
Logical reads:?? ?4,287.6?? ?483.6?? ? ?? ?
Block changes:?? ?436.4?? ?49.2?? ? ?? ?
Physical reads:?? ?100.5?? ?11.3?? ? ?? ?
Physical writes:?? ?40.6?? ?4.6?? ? ?? ?
User calls:?? ?261.7?? ?29.5?? ? ?? ?
Parses:?? ?108.9?? ?12.3?? ? ?? ?
Hard parses:?? ?0.1?? ?0.0?? ? ?? ?
W/A MB processed:?? ?0.9?? ?0.1?? ? ?? ?
Logons:?? ?3.1?? ?0.4?? ? ?? ?
Executes:?? ?263.1?? ?29.7?? ? ?? ?
Rollbacks:?? ?0.0?? ?0.0?? ? ?? ?
Transactions:?? ?8.9?? ? ?? ? ?? ?

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:?? ?100.00?? ?Redo NoWait %:?? ?100.00
Buffer Hit %:?? ?99.86?? ?In-memory Sort %:?? ?100.00
Library Hit %:?? ?99.63?? ?Soft Parse %:?? ?99.92
Execute to Parse %:?? ?58.61?? ?Latch Hit %:?? ?99.90
Parse CPU to Parse Elapsd %:?? ?3.12?? ?% Non-Parse CPU:?? ?98.36

Shared Pool Statistics


從load Profile 看到，
節點1 讀多些，Logical reads:13,716.1；Physical reads:365.3
節點2 寫多些? Block changes: 436.4；Physical writes:40.6；Executes：263.1；
有可能是在RAC服務上做了讀寫分離；


EMSTA1 節點
?? ?Top 5 Timed Foreground Events

?? ?Event?? ?Waits?? ?Time(s)?? ?Avg wait (ms)?? ?% DB time?? ?Wait Class
?? ?DB CPU?? ? ?? ?3,919?? ? ?? ?82.41?? ?
?? ?SQL*Net message from dblink?? ?42,752?? ?266?? ?6?? ?5.59?? ?Network
?? ?direct path read?? ?24,606?? ?211?? ?9?? ?4.43?? ?User I/O
?? ?db file scattered read?? ?18,913?? ?65?? ?3?? ?1.37?? ?User I/O
?? ?log file sync?? ?18,131?? ?52?? ?3?? ?1.09?? ?Commit


EMSTA2 節點
?? ?Top 5 Timed Foreground Events

?? ?Event?? ?Waits?? ?Time(s)?? ?Avg wait (ms)?? ?% DB time?? ?Wait Class
?? ?DB CPU?? ? ?? ?4,446?? ? ?? ?54.24?? ?
?? ?SQL*Net more data from client?? ?395,909?? ?2,438?? ?6?? ?29.74?? ?Network
?? ?SQL*Net break/reset to client?? ?106,466?? ?766?? ?7?? ?9.34?? ?Application
?? ?db file sequential read?? ?59,886?? ?473?? ?8?? ?5.77?? ?User I/O
?? ?log file sync?? ?172,878?? ?459?? ?3?? ?5.59?? ?Commit


從兩個節點中的 log file sync 也可以看到，節點1比節點2少很多。也可以認證
RAC服務上做了讀寫分離.
節點2 的后臺等待事件中 Network 等待占了29.74%
節點1 的后臺等待事件中 Network 等待占了5.59%
而NETWORK 等待都是第一位，說明有可能網絡狀況有改善的空間。


EMSTA1? Foreground Wait Class

?? ?Wait Class?? ?Waits?? ?%Time -outs?? ?Total Wait Time (s)?? ?Avg wait (ms)?? ?%DB time
?? ?DB CPU?? ? ?? ? ?? ?3,919?? ? ?? ?82.41
?? ?User I/O?? ?54,051?? ?0?? ?313?? ?6?? ?6.59
?? ?Network?? ?2,764,596?? ?0?? ?288?? ?0?? ?6.05
?? ?Commit?? ?18,131?? ?0?? ?52?? ?3?? ?1.09
?? ?Cluster?? ?73,832?? ?0?? ?52?? ?1?? ?1.09
?? ?Application?? ?2,526?? ?0?? ?6?? ?2?? ?0.13
?? ?System I/O?? ?6,580?? ?0?? ?4?? ?1?? ?0.09
?? ?Other?? ?536,299?? ?100?? ?4?? ?0?? ?0.08
?? ?Concurrency?? ?13,059?? ?0?? ?1?? ?0?? ?0.03
?? ?Administrative?? ?1?? ?100?? ?0?? ?100?? ?0.00
?? ?Configuration?? ?0?? ? ?? ?0?? ? ?? ?0.00


EMSTA2? Foreground Wait Class

?? ?Wait Class?? ?Waits?? ?%Time -outs?? ?Total Wait Time (s)?? ?Avg wait (ms)?? ?%DB time
?? ?DB CPU?? ? ?? ? ?? ?4,446?? ? ?? ?54.24
?? ?Network?? ?3,226,353?? ?0?? ?2,479?? ?1?? ?30.24
?? ?Application?? ?106,633?? ?0?? ?781?? ?7?? ?9.53
?? ?User I/O?? ?148,589?? ?0?? ?544?? ?4?? ?6.63
?? ?Commit?? ?172,878?? ?0?? ?459?? ?3?? ?5.59
?? ?Other?? ?1,196,388?? ?53?? ?122?? ?0?? ?1.49
?? ?Cluster?? ?166,036?? ?0?? ?110?? ?1?? ?1.35
?? ?System I/O?? ?6,580?? ?0?? ?4?? ?1?? ?0.05
?? ?Concurrency?? ?3,705?? ?1?? ?4?? ?1?? ?0.04
?? ?Configuration?? ?3?? ?0?? ?0?? ?40?? ?0.00


?? ?從兩節點的后臺等待類型也可以看出，
?? ?Network 等待是在節點2 第一位，節點1 是第二位；在節點2寫數據時，尤其突出。
Foreground Wait Events
節點1：SQL*Net message from dblink 42,752?? ?5.59%?? ?(bg time)?? ?

節點2：SQL*Net message from dblink 395,909?? ?29.74%?? ?(bg time)

?? ??? ?log file parallel write 174,063?? ??? ?22.46%?? ?(bg time)
?? ??? ?db file parallel write?? ?230,431?? ??? ?14.00%?? ?(bg time)



節點1

?? ?Top 5 Timed Foreground Events

?? ?Event?? ?Waits?? ?Time(s)?? ?Avg wait (ms)?? ?% DB time?? ?Wait Class
?? ?DB CPU?? ? ?? ?3,919?? ? ?? ?82.41?? ?
?? ?SQL*Net message from dblink?? ?42,752?? ?266?? ?6?? ?5.59?? ?Network
?? ?direct path read?? ?24,606?? ?211?? ?9?? ?4.43?? ?User I/O
?? ?db file scattered read?? ?18,913?? ?65?? ?3?? ?1.37?? ?User I/O
?? ?log file sync?? ?18,131?? ?52?? ?3?? ?1.09?? ?Commit




節點2
?? ?Top 5 Timed Foreground Events

?? ?Event?? ?Waits?? ?Time(s)?? ?Avg wait (ms)?? ?% DB time?? ?Wait Class
?? ?DB CPU?? ? ?? ?4,446?? ? ?? ?54.24?? ?
?? ?SQL*Net more data from client?? ?395,909?? ?2,438?? ?6?? ?29.74?? ?Network
?? ?SQL*Net break/reset to client?? ?106,466?? ?766?? ?7?? ?9.34?? ?Application
?? ?db file sequential read?? ?59,886?? ?473?? ?8?? ?5.77?? ?User I/O
?? ?log file sync?? ?172,878?? ?459?? ?3?? ?5.59?? ?Commit

從兩個節點的前臺等待事件中看到，第一位的都是DB CPU,而USER I/O 相對都比較少。
應該是一個OLTP 類的數據庫。


總結：

?? ?這是一個OLTP 類的 RAC 數據庫，并且做了讀寫業務分離，節點2 進行寫，節點1 負責數據讀；
?? ?從等待事件上來看。在網絡上應該可以進行性能調優，以減少在網絡的等待。

---------------------------------------------------------------------------------------------------
2.產生一個ASH報告，并進行分析，給出最后的結論。<br>

生成ASH 報告

創建腳本目錄：/opt/app/oracle/product/11.2.0/rdbms/admin/ashrpt.sql ?

ASH 創建：sqlplusTEST1/TEST1?? @創建腳本

[oracle@TEST1 ~]$ sqlplus / as sysdba

@ /opt/app/oracle/product/11.2.0/rdbms/admin/ashrpt.sql ?

選擇開始日期為 23-Dec-13 07:00:00 ,結束日期為當前時間
輸出文件名： ashrpt_racdb1_0102.txt


對內容進行分析：

ORACLE 環境： 這是一個RAC環境，節點名：RAC1
版本號: 11.2.0.3
CPU: 24顆；
SGA： 31,857M



ASH Report For RACDB/racdb1

DB Name???????? DB Id??? Instance???? Inst Num Release???? RAC Host
------------ ----------- ------------ -------- ----------- --- ------------
RACDB????????? 809919918 racdb1????????????? 1 11.2.0.3.0? YES rac1

CPUs?????????? SGA Size?????? Buffer Cache??????? Shared Pool??? ASH Buffer Size
---- ------------------ ------------------ ------------------ ------------------
? 24???? 31,857M (100%)??? 15,936M (50.0%)???? 4,186M (13.1%)?????? 61.0M (0.2%)


????????? Analysis Begin Time:?? 23-Dec-13 07:00:00
??????????? Analysis End Time:?? 02-Jan-14 17:11:46
???????????????? Elapsed Time:??? 15,011.8 (mins)
??????????? Begin Data Source:?? DBA_HIST_ACTIVE_SESS_HISTORY
???????????????????????????????? in AWR snapshot 33147
????????????? End Data Source:?? DBA_HIST_ACTIVE_SESS_HISTORY
???????????????????????????????? in AWR snapshot 34472
????????????????????????????????? + V$ACTIVE_SESSION_HISTORY
???????????????? Sample Count:???? 226,734
????? Average Active Sessions:??????? 2.52
? Avg. Active Session per CPU:??????? 0.10
??????????????? Report Target:?? None specified




Top User Events???????????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

?????????????????????????????????????????????????????????????? Avg Active
Event?????????????????????????????? Event Class??????? % Event?? Sessions
----------------------------------- --------------- ---------- ----------
CPU + Wait for CPU????????????????? CPU????????????????? 43.89?????? 1.10
log file sync?????????????????????? Commit?????????????? 16.39?????? 0.41
db file sequential read???????????? User I/O???????????? 13.69?????? 0.34
null event????????????????????????? Other???????????????? 3.94?????? 0.10
direct path read??????????????????? User I/O????????????? 2.87?????? 0.07
????????? -------------------------------------------------------------
前5個用戶等待事件中，CPU 等待第一位，CPU還是很高的。
第二位為log file sync,環境為RAC+DATAGUARD,可能也有影響。但總的來說還是很高的，
比后面的USER I/O還高。
這點有待查找問題。



Top Background Events?????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

?????????????????????????????????????????????????????????????? Avg Active
Event?????????????????????????????? Event Class???? % Activity?? Sessions
----------------------------------- --------------- ---------- ----------
LNS wait on SENDREQ???????????????? Network?????????????? 2.73?????? 0.07
CPU + Wait for CPU????????????????? CPU?????????????????? 2.67?????? 0.07
log file parallel write???????????? System I/O??????????? 2.09?????? 0.05
LGWR-LNS wait on channel??????????? Other???????????????? 2.01?????? 0.05
db file parallel write????????????? System I/O??????????? 1.57?????? 0.04
????????? -------------------------------------------------------------

后臺等待事件中第一位的是 LNS wait on SENDREQ，NETWORK等待事件，
還有第4位也是 LGWR-LNS 這可能也和DATAGUARD有關。




Top Cluster Events????????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

????????????????? No data exists for this section of the report.
????????? -------------------------------------------------------------

Top Event P1/P2/P3 Values?????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

Event????????????????????????? % Event? P1 Value, P2 Value, P3 Value % Activity
------------------------------ ------- ----------------------------- ----------
Parameter 1??????????????? Parameter 2??????????????? Parameter 3
-------------------------- -------------------------- --------------------------
log file sync??????????????????? 16.39????? "27704","1055995623","0"?????? 0.00
buffer#??????????????????? sync scn?????????????????? NOT DEFINED

db file sequential read????????? 13.77?????????????? "8","72729","1"?????? 0.00
file#????????????????????? block#???????????????????? blocks

direct path read????????????????? 2.87?????????? "46","631424","128"?????? 0.00
file number??????????????? first dba????????????????? block cnt

log file parallel write?????????? 2.09?????????????????? "2","8","2"?????? 0.45
files????????????????????? blocks???????????????????? requests

db file parallel write??????????? 1.57????????? "1","0","2147483647"?????? 1.55
requests?????????????????? interrupt????????????????? timeout

????????? -------------------------------------------------------------
前5位集群事件中，日志同步為第一位，第4位還是日志并行寫等待，看來日志的同步有可能是個問題



Top Service/Module????????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

Service??????? Module?????????????????? % Activity Action?????????????? % Action
-------------- ------------------------ ---------- ------------------ ----------
racdb????????? httpd@SERVER_WEB03 (TNS?????? 24.55 UNNAMED???????????????? 24.55
?????????????? httpd@SERVER_WEB02 (TNS?????? 17.06 UNNAMED???????????????? 17.06
?????????????? httpd@SERVER_WEB04 (TNS?????? 14.21 UNNAMED???????????????? 14.21
?????????????? httpd@SERVER_WEB01 (TNS?????? 13.39 UNNAMED???????????????? 13.39
SYS$BACKGROUND UNNAMED?????????????????????? 12.39 UNNAMED???????????????? 12.39
????????? -------------------------------------------------------------

前5 位服務，列出了登錄的幾臺服務器，（PHP WEB SERVER).



?????????????????????????????????????????? Distinct??????????? Avg Active
SQL Command Type???????????????????????????? SQLIDs % Activity?? Sessions
---------------------------------------- ---------- ---------- ----------
UPSERT?????????????????????????????????????????? 12????? 32.94?????? 0.83
SELECT????????????????????????????????????????? 641????? 17.70?????? 0.45
INSERT????????????????????????????????????????? 212????? 10.38?????? 0.26
UPDATE????????????????????????????????????????? 123?????? 1.38?????? 0.03
????????? -------------------------------------------------------------

Top Phases of Execution???????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

幾種DML 的處理所占比率，可以看到，UPSERT占多數(merget insert)，也就是更新插入處理；



Top SQL with Top Events??????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

??????????????????????????????????????????????????????? Sampled #
???????????????? SQL ID???????????? Planhash??????? of Executions???? % Activity
----------------------- -------------------- -------------------- --------------
Event????????????????????????? % Event Top Row Source??????????????????? % RwSrc
------------------------------ ------- --------------------------------- -------
????????? az95ftjvyfryk?????????? 3487005615??????????????? 67877????????? 32.65
CPU + Wait for CPU?????????????? 29.47 TABLE ACCESS - BY INDEX ROWID?????? 22.89

為前幾位的SQL 這里不再列出。


Top DB Files

Top DB Files??????????????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)
-> With respect to Cluster and User I/O events only.

??????? File ID % Activity Event???????????????????????????? % Event
--------------- ---------- ------------------------------ ----------
File Name???????????????????????????????????????????? Tablespace
----------------------------------------------------- -------------------------
???????????? 15?????? 1.47 db file sequential read????????????? 1.35
+DATA/racdb/datafile/idx_tbs_01.dbf?????????????????? IDX_TBS

???????????? 16?????? 1.36 db file sequential read????????????? 1.25
+DATA/racdb/datafile/idx_tbs_02.dbf?????????????????? IDX_TBS

???????????? 17?????? 1.28 db file sequential read????????????? 1.17
+DATA/racdb/datafile/idx_tbs_03.dbf?????????????????? IDX_TBS

???????????? 24?????? 1.25 read by other session??????????????? 0.81
+DATA/racdb/datafile/users_06.dbf???????????????????? USERS

???????????? 22?????? 1.17 db file sequential read????????????? 0.69
+DATA/racdb/datafile/card_tbs_04.dbf????????????????? CARD_TBS

列出訪問的數據文件排名，也可以從這里看到數據訪問的熱點，從而可以優化熱塊問題。

Top Latches???????????????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)

????????????????? No data exists for this section of the report.
????????? -------------------------------------------------------------

Activity Over Time???????????? DB/Inst: RACDB/racdb1? (Dec 23 07:00 to 17:11)
-> Analysis period is divided into smaller time slots
-> Top 3 events are reported in each of those slots
-> 'Slot Count' shows the number of ASH samples in that slot
-> 'Event Count' shows the number of ASH samples waiting for
?? that event in that slot
-> '% Event' is 'Event Count' over all ASH samples in the analysis period

???????????????????????? Slot?????????????????????????????????? Event
Slot Time (Duration)??? Count Event???????????????????????????? Count % Event
-------------------- -------- ------------------------------ -------- -------
07:00:00 (300.0 min)??? 4,947 CPU + Wait for CPU??????????????? 2,564??? 1.13
????????????????????????????? log file sync?????????????????????? 742??? 0.33
????????????????????????????? db file sequential read???????????? 702??? 0.31
12:00:00 (1,500.0 mi?? 20,128 CPU + Wait for CPU?????????????? 10,891??? 4.80
????????????????????????????? log file sync???????????????????? 2,759??? 1.22
????????????????????????????? db file sequential read?????????? 2,505??? 1.10
13:00:00 (1,500.0 mi?? 19,875 CPU + Wait for CPU?????????????? 11,262??? 4.97
????????????????????????????? log file sync???????????????????? 2,729??? 1.20
????????????????????????????? db file sequential read?????????? 2,132??? 0.94
14:00:00 (1,500.0 mi?? 23,296 CPU + Wait for CPU?????????????? 11,101??? 4.90
????????????????????????????? db file sequential read?????????? 4,033??? 1.78
????????????????????????????? log file sync???????????????????? 3,459??? 1.53
15:00:00 (1,500.0 mi?? 21,380 CPU + Wait for CPU?????????????? 10,545??? 4.65

LATCH 情況，從表中可以看到，更多的還是db file sequential read,及日志同步。


---------------------------------------------------------------------------------------------------
3.分析說明ASH和AWR報告的使用場景。<br>

ASH 報告是基于SESSION 級別，每秒采樣一次，記錄活動會話的等待事件，不活動的會話不會采樣，它能提供更為詳細的統計信息。
信息來源為V$ACTIVE_SESSION_HISTORY,
當視圖容量滿后，會被覆蓋，被覆蓋前，會把那部分數據保存在dba_hist_active_sess_history視圖；

AWR 報告是一種數據庫的全局性能診斷報告，它是對系統整體進行動態采樣收集快照信息，的一個分析表。

所以AWR 報告更加全面，能從各個環節反映數據庫性能問題；
如果我們要對數據庫做全面診斷時，一般會使用AWR.

ASH 能從會話層面，更詳細的反映會話問題。
如果要了解會話級詳細分析時，會使用ASH.

總結

以上是生活随笔為你收集整理的【性能优化】 之AWR 报告分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。