OS与Oracle

本文要分析的是下面这个SQL，执行了半个多钟头还没返回结果。
Wait events 是了解Oracle运行状态的一个重要途径。对于某个具体的SQL，SQL Monitor Report提供了drill down的方式得到这个具体SQL在运行中的wait events的分布情况，下面是SQL Monitor Report的相应图形。
这里最突出的等待事件是enq: TS – contention，这是关于临时segment的等待事件，这可能是一般的表空间的争用(例如并行直接路径加载数据)，也可能是临时表空间的争用(例如为了hash join或者sort)。那么这时临时表空间的增长状态是怎么样子的呢？SQL Monitor Report提供了这方面的信息……

SQL Monitor Report是11g推出的一个新特性。如果说11gR1里的SQL Monitor Report已经达到可圈可点的程度，那么11gR2里的SQL Monitor Report可以说已经接近完美了。

这个SQL Monitor Report包含的信息比单纯的Execution Plan可全面多了，基本上，有了这份报告之后，troubleshooting所需要的大部分信息都已经具备了。

这个Report主要包括以下五部分……

周末翻阅了以前写在msn space上的文章，不经意间找到了一篇2006年写的关于Linux内核的文章，那时想不到自己会变成一个Database Performance Engineer，不过里面的一些观点却和现在的工作不谋而合，只不过那时面对的Linux Kernel，现在面对的却是Oracle Database……

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。
我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止……

有一次跟一个QQ上的朋友一起探讨了另一个对系统CPU进行度量的指标: CPU used by this session。
他刚好有一份AWR报告，在这份报告里，出现了严重的CPU used by this session和DB CPU不一致的现象……

构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似insert /*+ append */ into table select from external_table的方式进行加载。
数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。
这个过程的AWR报告会是怎么样子的呢……

如何得到系统大致的MBPS呢？
MBPS= (Physical reads + Physical writes) * Block_Size = (196,271.4+2.0)*8*1024/1024/1024 = 1533 MB/s
更准确的MBPS可以从Instance Activity Stats部分获得……

上一篇文章提到的那些个工具，主要侧重点在于实时监控，而在我看来，实时监控只是一个监控工具的一个职责而已。就如Linux上的collectl或者nmon一样，我们还需要对这些历史性能数据进行保存，以便于过后进行分析。而且，这也是一个不可或缺的功能，毕竟，DBA不会也不可能24小时盯着屏幕，DBA做的主要事情应该是对历史数据进行分析从而更好的认识数据库的工作状态。

监控工具方面，也有很多实现这方面需求的软件。记得anySQL.net上面就有一个类似的监控工具。通过收集v$sysstat和v$session的数据，再利用图表的方式进行分析。这应该是这类软件的共性。

但有一个”工具”值得大提特提，那就是Oracle自身的AWR。AWR默认一个小时对系统做一次快照，这些快照其实是难得的历史性能数据，Oracle自带的AWR报告，主要是基于两个快照间的分析，因此只能得到一些孤立的数值。如果我们能够更进一步，实现对所有快照数据的分析，我们就能清晰地了解系统过去一段时间（默认AWR保留7天）的工作负载的特征曲线，各种重要指标的变化曲线。我想，这些曲线对于DBA或者决策层而言都是极其有用的……

写了Linux上的监控与分析工具之后，写写Oracle上相应的监控与分析工具还是挺有意思的，一方面可以更加完整，一方面可以进行横向对比。

Linux上的性能数据一般都来自于/proc文件系统，而Oracle则是来自于V$视图。因此，所有的Oracle监控工具的实现都万变不离V$ 视图。而这些个视图里面，最重要的应推v$sysstat。里面记录着Instance一级的各个统计数据的当前值，例如CPU利用情况，逻辑读，Redo Size等等。10g后有了另一个重要的视图，叫v$active_session_history,通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的处理，就可以清晰地了解系统的历史工作负载特征和压力。如果想获取当前正在执行的SQL，则可查询v$sql视图。如果想获取当前SQL的执行计划，则可调用dbms_xplan.display_cursor。从这方面讲，一个DBA都具备着写一个Oracle的监控工具的能力。它应该比写一个Linux的监控工具来得容易简单得多……

除了上一篇文章提到的collectl, IBM出品的nmon其实也是一个不错的Linux上的性能监控工具，在写这篇文章时顺带google了nmon一把，惊喜地发现nmon也open source了。还是以sourceforge为根据地，网址是http://nmon.sourceforge.net.

nmon在监控数据与易用性方面几乎与collectl不相上下，对监控单台机器的系统性能还是不错的选择的。

不过，nmon却做出了另一个突出贡献。这就是推出了一个nmon analyser，而且以开放源代码的形式提供，它的目的是实现对nmon产生的历史性能数据的分析，产生一系列的图表。nmon analyser其实就是一个Excel文件，里面嵌套了VBA脚本用来分析nmon产生的文本文件并产生一系列的图形报表。深入地分析这些脚本，你会发现，这个analyser其实是一个极好的框架，很容易利用这个analyser来分析自己的数据，而不局限于nmon产生的文件……