awr报告 解读_关于AWR报告的解析「建议收藏」

awr报告 解读_关于AWR报告的解析「建议收藏」其实,网上关于AWR的解析已经足够多了。但总觉得通过收集资料,再加工写出来的资料能便于自己理解其中的各项内容,因此我对AWR进行一篇详尽的解析。希望能分几次完成从AWR报告的第一部分包含了数据库的名称、数据库的ID号、实例名、实例数、启动的时间、数据库版本和是否为RAC。此外也包含了系统的部分信息。该部分最关键的内容是第三个模块,里面记录了snapshot的开始时间和结束时间,以及数据库运行时间和...

其实,网上关于AWR的解析已经足够多了。但总觉得通过收集资料,再加工写出来的资料能便于自己理解其中的各项内容,因此我对AWR进行一篇详尽的解析。希望能分几次完成

awr报告 解读_关于AWR报告的解析「建议收藏」

从AWR报告的第一部分包含了数据库的名称、数据库的ID号、实例名、实例数、启动的时间、数据库版本和是否为RAC。此外也包含了系统的部分信息。

该部分最关键的内容是第三个模块,里面记录了snapshot的开始时间和结束时间,以及数据库运行时间和用户级别调用(session)所消耗的时间。

DB CPU:Amount of CPU time (in microseconds) spent on database user-level calls. This does not include the CPU time spent on instance background processes such as PMON.

这里就涉及一个问题,通过数据库用户调用的时间可以算出数据库繁忙的程度。首先来看看Elapsed Time为1664.70 mins 折算成秒为

Elasped Time=(1664*60+.7*60)/3600 hours

看下snapshot begin to end 时间为27 hours 44 mins 42 sec 刚好就是Elasped Time的时间。

系统有32个CPUs,因为并行作业的缘故,总计DB在CPU上消耗的时间应为32*1664.7 而DB Time的时间为在所有CPUs上消耗的时间106.76 mins。

从这里我们就可以算出数据库用户级别消耗的时间比:106.76/32*1664.7*100%≈0.2%

也就是说DB在CPU上的使用率为0.2%,idle rate达到99.8%。说明数据库负载相当的低。

DB Time既然为用户级别的调用,具体包含什么呢?我这里直接引用网上的公式。

DB Time= DB CPU + Non-Idle Wait + Wait on CPU queue

awr报告 解读_关于AWR报告的解析「建议收藏」

通过查看CPU的负载大概可以印证这个数据。

第二部分

awr报告 解读_关于AWR报告的解析「建议收藏」

报告概要的Cache Sizes很简单,主要包含buffer的尺寸、shared pool大小、标准块大小、日志buffer的大小。

正如我们所知的,Oracle DB采用LRU算法,将数据块内容缓存至Buffer中,进行数据的加速读取访问操作,而对于已经修改过的Dirty Buffer,又通过Cache和DBWR进程写回到数据文件中。因此对于一个OLTP(On-Line Transaction Processing)型数据库Buffer Cache是相当重要的。

数据库CPU负载状况分析

awr报告 解读_关于AWR报告的解析「建议收藏」

DB Time(s)=DB Time/Elasped,这里得出的是近似值。可以理解为在数据库运行的这个时段中,DB在调用方面消耗的时间。

DB CPU(s) 表示DB Time时间内,有约0.1S是消耗在CPU上的。

而CPU繁忙程度则需要观察Instance CPU中的Busy CPU项

awr报告 解读_关于AWR报告的解析「建议收藏」

可以看出该数据库该时间段内CPU 繁忙度为45.4%也是相当空闲的。

Transactions:说明数据库每秒处理事务的个数为71.2,那么这段时间段内总处理的事务数公式:

总事务数=Transactions*Elasped=71.2*1664.7*60=

事务的效能比

awr报告 解读_关于AWR报告的解析「建议收藏」

Buffer Nowait:非等待Buffer事件比

Buffer Hit:Buffer命中率

Library Hit %:库命中率,主要针对数据库的字典信息的查询

Execute to Parse:用于解析的执行比

Parse CPU to Parse Elapsd:CPU解析在整个解析中的时间比

Redo Nowait:非等待Redo事件比

In-memory Sort:内存中的排序的事件比

Soft Parse:在总的解析次数中软解析比率

Latch Hit:闩的命中率

% Non-Parse CPU:非解析CPU使用比

共享池状态

awr报告 解读_关于AWR报告的解析「建议收藏」

SQL with executions:超过1次被调用的SQL语句比例

Memory for SQL w/exec:内存中SQL写操作超过1次比例

占用时间前五的前台事件(Top 5 Timed Foreground Events)

awr报告 解读_关于AWR报告的解析「建议收藏」

DB CPU:占用的时间6411秒, 在整个DB Time时间中占用比为100.09% 说明CPU消耗很高。

log file sync:写入日志文件时间为424秒 占比424/6411*100%近似值

direct path read:

SQL*Net message to client:客户端连接时间

cursor: pin S 游标时间

这里Avg wait(ms)的换算是有Time(s)/Waits获得的。上面反映的数据 如log file sync几乎为0,说在该时段内log file sync单次等待的时间近乎为0毫秒(实际值0.06ms) 。这里表明没有发生因日志的写导致的IO迟缓的问题。

按SQL执行耗时排序 awr报告 解读_关于AWR报告的解析「建议收藏」

而DB CPU一般都发生在执行SQL语句和调用Procedure的时候,这里我们来观察SQL order by CPU

awr报告 解读_关于AWR报告的解析「建议收藏」

上面的显示了SQL执行的时间占CPU Time前10的SQL语句,在上面Top 5 foreground events中CPU time总计消耗了6411秒,而SQL执行消耗DB CPU时间总计为5359.64秒(%Total)。占了约83.6%的比例。

%CPU是在语句执行消耗的时间中CPU Time的时间比,即CPU Time(s)/Elasped Time(s)

%IO是语句执行的IO时间和Elasped Time比,即IO Time(s)/Elasped Time(s) in Read,通过IO的比可以看到哪些语句的物理读占用比较多,同样可以在SQL order by Read表中获取

awr报告 解读_关于AWR报告的解析「建议收藏」

通过Reads表可以观察到SQL的物理读的情况,这里的Elasped Time(s)就是用于计算%IO的基数。

awr报告 解读_关于AWR报告的解析「建议收藏」

通过这个观察,可以看到其中IO读最多的一个语句是SQLPLUS工具中调用了一个语句,很明显该语句的参数了大量的物理读操作。那么就要考虑该语句的优化了。接下来可以观察SQL的逻辑读部分。Gets表示的是SQL语句在Buffer中获取的数据量

awr报告 解读_关于AWR报告的解析「建议收藏」

里面统计的Total Buffer Gets总值为527,755,991,%Total=Buffer Gets/Total Buffer Gets

这里的SQL发生总Buffer Gets为784,209,002

To Be Continue...... : P

架构君码字不易,如需转载,请注明出处:https://javajgs.com/archives/222425
0
 

发表评论