【性能优化】 之AWR 报告分析
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 报告分析相关推荐
- oracle性能优化之awr分析
oracle性能优化之awr分析 作者:bingjava 最近某证券公司系统在业务期间系统运行缓慢,初步排查怀疑是数据库存在性能问题,因此导出了oracle的awr报告进行分析,在此进行记录. 导致系 ...
- oracle awr报告生成_oracle11g awr报告分析—WORKLOAD REPOSITORY report
概述 关于生产环境的一份awr报告分析,之前闲着无聊整理了100页,后面拆分下各个模块介绍下怎么看awr报告. 我们在看性能指标的时候,需要知道数据库出现性能问题,一般都在三个地方,io,内存,cpu ...
- oracle pdf response,AWR报告分析之二：ges inquiry response 过高
AWR报告分析之二:ges inquiry response 过高 在一个朋友AWR报告中,ges inquiry response事件过高引起了忧虑.这个等待事件来自RAC集群,这里的GES指Glo ...
- JVM性能优化之GC日志分析
JVM性能优化之GC日志分析 文章目录 JVM性能优化之GC日志分析 前言 一.GC日志参数 GC日志参数 常用的垃圾收集器配置 大对象回收 二.GC日志分析工具 GCeasy JVM memory ...
- 字节跳动Android三面视频解析：framework+MVP架构+HashMap原理+性能优化+Flutter+源码分析等
前言 对于字节跳动的二面三面而言,Framework+MVP架构+HashMap原理+性能优化+Flutter+源码分析等问题都成高频问点!然而很多的朋友在面试时却答不上或者答不全!今天在这分享下这些 ...
- awr报告分析 mysql_4个MySQL优化工具，帮你准确定位数据库瓶颈！
作者:老王谈运维原文:https://www.toutiao.com/a6691523026984370699/ 对于正在运行的mysql,性能如何,参数设置的是否合理,账号设置的是否存在安全隐患,你 ...
- Oracle的AWR报告分析
* 定义:awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告 ...
- 手工收集awr报告_一个Oracle小白的AWR报告分析（一）
背景:某个类似准实时的数据分析系统,每15分钟从其他6个数据库中抽取五百张增量数据表,并进行15分钟粒度统计,同时有个前端门户进行查询. 该数据分析系统由数据抽取服务器.应用服务器.数据库服务器组成, ...
- oracle10g生成awr报告,oracle 10g awr报告生成步骤及awr报告分析
3. io:如果需要的数据在内存中没有,则需要到磁盘中去取,就会用到物理io了,还有表之间的连接数据太多,以及排序等操作内存放不下的时候,也需要用到临时表空间,也就用到物理io了 这里有一点说明的是, ...
最新文章
- OpenCV（一）图像读取与新建、图像显示、操作图像像素（2种涂色并比较算法优劣、输出RGB）
- 【学习笔记】git 使用文档
- shell脚本报错：[: =: unary operator expected
- VMware和Linux版本搭配问题
- qt-designer使用教程1--HelloWorld
- VMware vSAN6.7 设计和优化 vSAN 主机--
- 一起玩树莓派3+手把手带您入门树莓派（3000字+超详细图解版）
- antd 嵌套子表格_大型前端项目架构优化探索之路腾讯文档表格
- Ubuntu 16.04安装 sogou 遗留下的问题
- 【Trie】最大异或对（ybtoj Trie-2）
- Web前端文档阅读笔记-vis.js动态添加节点（vue cli环境）
- 【java】java 如何证明linux缓存行确实存在
- 简单了解阿里云Web应用防火墙（下篇）
- 8.Python进阶_异常处理
- 用友T1商贸宝批发零售版SQL SERVER数据库恢复
- google code jam 2008 Mousetrap (逆向)
- 个人设计和公司设计，哪个更适合你？
- Halcon椭圆测量
- ms721调试总结及光电传感器板测试总结
- 回溯算法（回溯搜索法）