AWR报告分析-实战1
构建 DSS 系统的第一步离不开数据加载,通过文本文件加载是最常见的方式,Oracle 提供了外部表加载的方法,即把一个文本文件当成一个正常的表来进行操作,通过类似 insert /*+ append */ into table select from external_table 的方式进行加载。
数据加载是一个 CPU-Bound 的过程,不过是通过什么工具,external table 也好,sqlldr 也好,imp 也好,impdp 也好。换句话说,如果连数据加载都出现 IO 瓶颈,这个系统的配置就说不过去了。
这个过程的 AWR 报告会是什么样子的呢?
先做个一般的假定,从外部表加载数据到一个本地分区表。
Top 5 TimedEvents 类似下面:
如果去抓取这段时间 DBA_HIST_ACTIVE_SESS_HISTORY 的数据,并转换为图表的话,我们会得到更形象的 Top 10 Wait Events。(如何实现这一步可以参考用 Oracle 实现 ASH 的数据透视图:http://www.cnblogs.com/rootq/archive/2009/09/24/1573200.html)
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 标记。下面是一个例子:
一个好消息是,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 不一致的现象。
下面是这份报告的一些片断:
再做进一步的归纳:
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 时,我们发现了下面的现象:
这是从 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,这个误差很有可能会被放大。这是一个有趣的实际例子。