0

AWR 报告深度解读:两则实战分析

黄凯耀 2019-09-05
990

AWR报告分析-实战1


构建 DSS 系统的第一步离不开数据加载,通过文本文件加载是最常见的方式,Oracle 提供了外部表加载的方法,即把一个文本文件当成一个正常的表来进行操作,通过类似 insert /*+ append */ into table select from external_table 的方式进行加载。

数据加载是一个 CPU-Bound 的过程,不过是通过什么工具,external table 也好,sqlldr 也好,imp 也好,impdp 也好。换句话说,如果连数据加载都出现 IO 瓶颈,这个系统的配置就说不过去了。

这个过程的 AWR 报告会是什么样子的呢?
先做个一般的假定,从外部表加载数据到一个本地分区表。

Top 5 TimedEvents 类似下面:

1.jpg


如果去抓取这段时间 DBA_HIST_ACTIVE_SESS_HISTORY 的数据,并转换为图表的话,我们会得到更形象的 Top 10 Wait Events。(如何实现这一步可以参考用 Oracle 实现 ASH 的数据透视图:http://www.cnblogs.com/rootq/archive/2009/09/24/1573200.html

2.jpg


enq: HV –contention 是什么东西呢?

在11.2以前,对于分区表的 parallel direct-path load,Oracle 采用的是 brokered load 的方式,即所有的 PX Slaves 共享对每个分区的 high water mark 的访问,通过轮流持有 high water mark 实现对每个 segment 添加新的 blocks。这种方法对于充分利用 extent 的空间是有帮助的,不过带来的问题就是对 high water mark 的竞争,也就是这里的 enq: HV – contention。在执行计划中,这以 RANDOM LOCAL 标记。下面是一个例子:

3.jpg


一个好消息是,11.2引入了一种新的方式,叫做 PKEY distribution。在这种方式下,一个特定的分区只交给一个或多个特定的 PX slave 负责,这种方式不仅减少了对 high water mark 的争用,而且可以实现 Partition 内更好的压缩率。

AWR报告分析 – 实战2


有一次跟一个 QQ 上的朋友一起探讨了另一个对系统 CPU 进行度量的指标: CPUused by this session。

他刚好有一份 AWR 报告,在这份报告里,出现了严重的 CPU used by this session 和 DB CPU 不一致的现象。

下面是这份报告的一些片断:

4.jpg

5.jpg

6.jpg

7.jpg


再做进一步的归纳:

OS Busy% =1821080/(1821080+5384293) = 25%
Inst CPU% (usingDB CPU) = 8934.22*100/ (1821080+5384293)=12%
Inst CPU% (usingCPU used by this session) = 418035/ (1821080+5384293) = 6%


用 CPU used by this session 计算出的 CPU 利用率竟然只是用 DB CPU 计算出来的利用通率的一半!

我的第一个反应是在 Jonathan Lewis 网站看到的一篇相关文章,里面提到了 DB CPU 和 CPUused by this session 计算时的不同之处: (https://jonathanlewis.wordpress.com/2009/05/26/cpu-used/)

“Prior to10g Oracle usually updated time figures at the end of each database call; butfrom 10g there are some views where time is updated more regularly.
The “DB CPU” from v$sess_time_model increases every six seconds, while the “CPU used by this session” from v$sesstat changes only at the end of the test.”


如何验证这一点呢?


在浏览这份报告的 TOP SQL 时,我们发现了下面的现象:

8.jpg


这是从 SQL ordered by Elapsed Time 截取出来的 Top 3 SQL。TOP 1 的 SQL 用了 DB Time 的30.10%,用了2517s 的 CPU Time。但请注意它的 Executions 的值却为0。也就是说,这里的 CPU Time 是还没有被计算入 CPU used by this session 这个指标里面的。

我们再把2517s加回来,看出误差缩小多少:

(251700+418035)/(1821080+5384293) = 9%


这时和用 DB CPU 计算出来的12%还是有1/4的差距。

从这个例子可以看出,用 DB CPU 度量还是比用 CPU usedby this session 来得准确的。特别在有大查询在跑的过程中抓的 AWR,这个误差很有可能会被放大。这是一个有趣的实际例子。

最后修改时间:2019-09-05 17:30:16
「喜欢文章,快来给作者赞赏墨值吧」
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部