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，这个误差很有可能会被放大。这是一个有趣的实际例子。
