【性能优化】 之AWR 报告分析
2014-01-23 14:02
337 查看
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的分析结论。<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.
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- <<Oracle数据库性能优化艺术（第五期）>> 第14周 性能报告分析（AWR，ASH）
- ORACLE 性能优化-查询数据库慢SQL（其实还是awr和ash报告更方便~）
- oracle性能优化之awr分析
- Oracle 实例性能分析与优化之AWR学习总结
- 生成oracle awr 性能分析报告
- 理论实践：循序渐进理解AWR细致入微分析性能报告
- 从AWR报告分析Oracle性能
- [原创-性能调优]借助AWR报告分析解决oracleCPU过高的问题
- 由浅入深探究mysql索引结构原理、性能分析与优化
- 借助AWR报告分析解决oracleCPU过高的问题（转）
- 【运维小分享】基于Web应用的性能分析及优化案例详解
- Android应用开发性能优化完全分析
- 带你玩转Visual Studio——性能分析与优化
- Oracle 10g AWR 报告分析
- 【Android应用开发技术：图像处理】Bitmap显示性能优化分析
- MySQL 性能优化神器 Explain 使用分析
- WebView性能、体验分析与优化
- 在线的图片、js、css压缩优化工具介绍（配合小强视频 前端性能分析精要）
- MMO移动游戏性能分析报告：渲染、UI、逻辑代码和内存