今天就跟大家聊聊有关如何进行ORACLE AWR性能报告和ASH性能报告的解读,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
数据库的性能分析可分为会话级和系统级:如果确定某个会话存在性能问题,最常见的分析方式是对这个会话做一个SQL_TRACE或者10046事件,通过分析trace文件来定位问题所在。如果无法确定哪个会话性能有问题,就需要从实例级别来分析问题所在。
awr是oracle 10g下提供的一种性能收集和分析工具,它能够提供一个时间段内整个系统资源使用情况的报告。
awr默认收集最近7天的采集信息,也可通过以下方法修改快照收集时间间隔信息。
awr由运行在oracle的后台进程自动、定期收集数据库的性能数据并保存,每一个小时,awr都生成一次性能数据快照,为DBA提供某个时刻数据库性能分析的数据信息。
执行$ORACLE_HOME/RDBMS/ADMIN/awrrpt.sql生成awr报告。
awr报告要根据系统实际情况(OLAP or OLTP)来进行分析,例如对于一个OLTP系统,library hit和buffer hit应比较关注。而对于OLAP不甚重要。
awr报告不需要全面阅读,全面阅读可能思路会更乱,如果性能问题由某个原因引起,那么会在报表的各个部分都会有相应呈现。
在RAC结构的数据库里做性能分析,通常需要对每个实例做一个awr性能报告,原因是无法知道每个用户连接到哪个实例当中去。
对于一个系统,需要多做几次awr报告,以便得到所有时间段的系统性能数据。在查看awr报告时,如果了解数据库业务,应该有针对性
的看一些可能存在性能问题的部分,并结合业务的实际情况来判断;也可以从TOP5的等待事件触发,按照等待事件的类型,
到相应的部分获取详细的信息来对系统性能问题作出判断。
通过awr报告可以:1)查看系统的负载和繁忙程度;2)查看系统的瓶颈,发生的等待事件;3)查看可优化的sql;
一、Report Summary:
1、SESSIONS:实例连接的会话数,数据库大概的并发用户数;
2、cursors/session:每个会话平均打开的游标数;
3、DB time:用户操作花费的时间的合集,包括CPU时间和等待事件;
4、cache sizes:列举awr在性能采集开始和结束的时候,数据缓冲池和共享池的大小,可以了解系统内存消耗的变化,可以判断SGA的内存分配是否合理;
5、load profile:数据库资源负载的一个明细列表,用来判断系统的繁忙程度。分割为每秒钟的资源负载和每个事务的资源负载情况。
6、Instance Efficiency Percentages:内存效率的统计信息,对于OLTP系统,应尽可能的接近100%。如果哪个数据偏低,就要做相关的分析研究。
1)buffer nowait:非等待方式获取数据库;
2)redo nowait:非等待方式获取redo数据;
3)buffer hit:内存数据块命中率;
4)in-memory sort:数据块在内存中排序的百分比;
5)library hit:共享池中sql解析的命中率;
6)execute to parse:执行次数对分析次数的百分比;
7)latch Hit:latch命中率百分比;
8)parse cpu to parse elapsed:解析总时间中消耗CPU的时间百分比;
9)non-parse cpu:cpu非分析时间在整个cpu时间的百分比;
7、TOP 5 TIMED EVENTS:查看最高5个耗费时间及等待事件,要联系报告的采集周期来看耗费时间是否合理。一般来说,CPU time出现在TOP5中的第一位,并且消耗时间占总时间的大部分比例。可以说明系统在正常运行。
对于ORACLE常见的等待事件可参考http://blog.itpub.net/29371470/viewspace-1063994/
以上这部分就是awr报告的总体概要,是需要重点关注的部分,根据这些信息可以知道等待时间比较长的事件,然后根据这些事件,去下面具体的部分查找问题原因。
二、Wait Events Statistics:
1、Time Model Statistics列出了各种操作占用的数据库时间比例;
2、Foreground Wait Class列出了等待事件类型,可以看到等待时间最长的事件;
3、Foreground Wait Events是第一部分TOP 5 TIMED EVENTS的详细部分;
4、Background Wait Events实例的后台进程等待事件;
三、SQL Statistics:
1、SQL ordered by Elapsed Time:按照sql的执行时间从长到短的排序;
1)CPU time:sql消耗的CPU时间;
2)elapsed time:sql执行时间;
3)executions:sql执行的次数;
4)elapsed per exec:每次执行消耗的执行时间;
2、SQL ordered by CPU Time:按照sql的CPU时间从长到短排序:
3、SQL ordered by User I/O Wait Time:
4、SQL ordered by Gets:按照sql获取的内存数据块的数量排序:
5、SQL ordered by Reads按照sql执行物理读排序:
6、SQL ordered by Physical Reads (UnOptimized):
7、SQL ordered by Executions:按照sql的执行次数的排序;
8、SQL ordered by Parse Calls:按照sql被分析次数(不区分软解析还是硬解析)的信息排序;
9、SQL ordered by Version Count:sql产生多版本的信息;version count是sql的版本数;
以上指标孤立起来看都没有实际意义,需要看系统的类型和性能问题是什么方面,有侧重的进行分析。例如SQL ordered by Executions和SQL ordered by Parse Calls对OLTP比较重要,而OLAP系统不需要太关注。
四、Instance Activity Statistics:
cpu used by this session:oracle消耗的cpu单位,可以看出cpu的负载情况;如果total为1000,per sec 为80,cpu个数为2;
那么就是整个统计周期消耗了1000个cpu单位,每秒钟消耗了80个cpu单位,对应实际的时间是80/100=0.8秒;每秒钟每个cpu消耗80/2=40个cpu单位;每秒钟中每个cpu处理使用的时间是40/100=0.4秒。
五、IO Stats:
Tablespace IO Stats:表空间的IO性能统计;
File IO Stats:
1)reads:发生了多少次物理读;
2)writes:发生了多少次写;
3)Av reads:每秒钟物理读的次数;
4)Av Rd:平均一次物理读的时间;
5)Blks/Rd:每次读多少个数据块;
6)Av writes:每秒钟写的次数;
7)buffer waits:获取内存数据块等待的次数;
segments by logical reads和segment by physical reads从对象角度来展现了IO情况,分析这两部分信息,可以具体知道哪些对象的访问导致了IO性能下降。
ASH侧重于当前数据中活动会话的信息分析,被长期保存在数据字典中,可以通过查询视图V$ACTIVE_SESSION_HISTROY来得到。
运行脚本为$ORACLE_HOME/RDBMS/ADMIN/ashrpt.sql
使用同目录下的ashrpti.sql脚本可以生成其他数据库或者实例的ASH性能报告,也可以对一个session ID、SQL_ID、某个程序或者某一类等待事件
来生成ASH报告,如下图:
ASH报告分析如下:
DATA SOURCE如果来自DBA_HIST_ACTIVE_SESS_HISTORY,那么说明这些信息来自于AWR的快照;如果来自于V$ACTIVE_SESSION_HISTORY,那么
视图的信息就意味着性能数据存放到内存中的信息。
1、top user events:用户会话的等待事件的信息;
2、top event p1/p2/p3 values:等待事件的具体描述;
3、top service/module:按照活动频率列出前五位的应用程序;
4、top sql command types:列出了数据库中活动最频繁的操作;
5、top sql statements:按活动频繁程度列出sql语句;
6、top session:列出活动最频繁的会话或进程;
7、top sessions running PQs:列出活动频繁的前几位并行执行的会话信息;
8、top DB files:IO最频繁的数据文件;
9、activity over time:按照一个时间间隔对采集时间周期分组后,生成的每个时间间隔里的等待事件信息。
看完上述内容,你们对如何进行ORACLE AWR性能报告和ASH性能报告的解读有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。