在Exadata上面的Retail Demo展示始于Exadata在2008年底在OOW上的发布。经过几年的发展与完善，在Oracle Real World Performance Group在全球各地所举行的各种培训活动中，Retail Demo极好的展示了Exadata各方面的卓越性能，使听众们对Exadata有着一个真实切身的体验。Retail Demo包括了众多数据仓库上的典型内容，如数据加载，增量数据加载，统计信息收集，数据验证和转换，随机查询，并发查询等等内容，里面融合着Oracle所提倡的最佳实践。

btw, 上次我在ACOUG分享的10分钟加载1TB数据的Demo即来源于此。

20分钟可以做哪些事情，下面是Retail Demo对此做的一个回答：

应广大人民群众的要求，Oracle Real World Performance Group终于推出了Retail Demo的录制视频，并共享在了youtube上面。总共分为四部分：

第一部分主要内容：
整个Demo的整体介绍，22节点实时性能监控窗口，EM监控窗口
数据仓库硬件发展趋势分析，硬件规划
1TB数据构成与HCC压缩
数据加载的特征,IO瓶颈? CPU瓶颈? 内存瓶颈？
Demo： 加载1TB 数据

第二部分主要内容：
数据压缩和分区对数据加载的影响
外部表的使用
Demo: 统计信息收集
11g的新特性:增量统计信息

第三部分主要内容：
使用服务进行增量加载
数据的有效性检查与转换
Demo：有效性检查
Demo: 数据转换

第四部分主要内容:
Demo: 随机复杂查询
数据库资源管理
Demo: 并发随机查询

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

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

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

对这些曲线进行部分展示的，就是Enterprise Manager了。在Performance这个Tab里面，可以选择按Historical浏览的方式。这其实就是对AWR Repository里的数据进行查询。不过EM只提供对一天时间跨度的drill down，所提供的曲线也比较有限，归纳起来，11g里EM提供的主要曲线有：

1. Average Active Sessions – 7 Day View
2. Host: Runnable Processes  – 1 Day
3. Average Active Sessions – 1 Day
4. Logon/Transaction Rate – 1 Day
5. Physical Reads/Redo Size Rate – 1 Day
6. Latency For Synchronous Single Block Reads – 1 Day
7. I/O Megabytes per Second by I/O Function – 1 Day
8. I/O Request per Second by I/O Function – 1 Day
9. Sessions of Parallel Execution – 1 Day
10. Active Sessions of Services – 1 Day

网络上实现类似功能的软件好象不多(知道的朋友请多comment一下)，不过，碰巧也找到了一个，叫做ONDATAPERF。通过用户上传一系列的Statspack或者AWR报告，最后据说会产生一个类似这个链接的ONDATAPERF report。这个报告里面的图表看起来还是很酷的，随便抓一个ASH的例子。

当然，唯一的缺点是这是一个付费服务。

其实，要自己实现类似的功能或者更全面的图表也不是很难的一件事情。可以考虑参考nmon的Analyser，做一个专门针对AWR Repository的Analayser出来。这应该是挺有意义，挺有先驱性的一件事情。要真有这个工具，说不定可以和这个ONDATAPERF 竞争一番呢!

写了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的监控工具来得容易简单得多。

如果对监控工具做下分类的话，可以分成两类，一类是基于文本模式的，一类是基于GUI模式的。大部分DBA都自己收集了一些很常见的监控脚本，我想可以把这一类归为基于文本模式的工具。文本模式的好处在于轻量级，反应速度快，比较适合在shell模式下和sqlplus协同工作。大部分DBA可能也比较习惯这个模式，包括我在内。

GUI模式用得较多的工具应该是Toad。很不错的一个工具，用它来监控sessions，session正在执行的语句，session的等待事件是我最常用的一个功能。

也有一些后起之秀，有个工具也许值得一提，叫做DB Optimizer。最主要的是这个产品的主要参与者：参与了10g EM里的Performance Page的重新设计的Kyle Hailey。以一个截图做为结尾吧:

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

nmon在监控数据与易用性方面几乎与collectl不相上下，对监控单台机器的系统性能还是不错的选择的。不过，nmon没有如collectl一样的网络接口，如果用来它实时监控几十台机器，可能要开几十个窗口，这基本上是不可能的事情。

下面是nmon官方网站最新版本的一个截图：

不过，nmon却做出了另一个突出贡献。这就是推出了一个nmon analyser，而且以开放源代码的形式提供，它的目的是实现对nmon产生的历史性能数据的分析，产生一系列的图表。

以图表分析性能数据的作用是很明显的。密密麻麻的数字，也许只有经过一定的聚合计算，人们才能大致地了解数据的含义，说得忽悠人一点，那就是数据挖掘。不过，聚合计算有个问题，就是会把系统可能出现的瓶颈掩盖掉，举个Jonathan Lewis打过的比方，一个人头部放在寒冰里，脚放在烈火中，按平均值理论，这个人会感觉得很舒服。而利用图形的方式对数据进行描述，就不会导致数据的丢失，而且会使数据特征一目了然。

还是一个来自官方网站上nmon analyser分析结果的一个截图：

nmon analyser其实就是一个Excel文件，里面嵌套了VBA脚本用来分析nmon产生的文本文件并产生一系列的图形报表。深入地分析这些脚本，你会发现，这个analyser其实是一个极好的框架，很容易利用这个analyser来分析自己的数据，而不局限于nmon产生的文件。举个例子，可以用nmon analyser来产生由collectl产生的文件。这当然需要对nmon analyser的脚本做一定的改写，下面是一个例子：

这里可能要做更深一步的说明，无论是nmon或者collectl，都提供了一种把它们做为后台daemon进程对系统进行监控并产生监控日志的功能。这些监控日志就可以被用于对系统的历史性能的分析。collectl甚至还做了一个功能，根据用户指定的时间跨度，自动地从日志里面抽取出这段时间里的历史数据。analyser的作用就在于分析这些日志，并产生相应的分析报告和图表。

因此，从某种程度上说，nmon anlayser为我们提供了一个框架，利用这个框架，我们可以利用起Excel强大的数据分析与绘图功能，实现对文本文件数据的自动处理。这才是本文要说明的最终结论。

对系统资源的监控，是系统管理者一个必备的任务。从OS角度讲，包括CPU/IO/Network/FS等等，从Database的角度讲，包括Active Sessions/ON CPU/Disks/Top Segments/Top SQL等等。而Database对资源的利用也反映在OS一级上，对OS计算资源的充分均衡利用是我们的目标。那么，如何有效的掌握OS的资源利用情况就成为了一个System Administrator，Database Administrator日常工作的一个重点。

Linux上的常规监控工具主要有top, vmstat, iostat, netstat, sar这些。对这些工具的熟练运用应该能解决大部分问题，不过，这些工具也太散了，学习周期是一个很大的问题。有没有一个包揽所有这些工具的一个超级命令呢？

这就是本文要推荐的一个工具了，collectl，一个开源的sourceforge上的项目，http://collectl.sourceforge.net。

先摆摆架构图

三种模式：

Interactive Mode: This is the default and in this mode data is read from /proc and passes through analyze.

Record Mode: Data passes from /proc the same way as Interactive Mode but instead of going through the Analyze function it written it to a file.

Playback Mode: Here collectl works virtually identical to Interactive Mode except instead of reading data from /proc it reads it from a file.

另一个摩登的，独此一家的，现成的特性是支持socket发送数据，这对于一个有几十台以上机器的cluster来说简直就是一个福音。可以通过另一个命令接收整个cluster里面所有机器实时发送过来的数据，通过一个屏幕显示出来，这对于掌握整个cluster的工作状态是极其方便的。

对于一般的机房来说，虽然机房里的所有机器不是一般意义上的cluster，但是也可以在所有机器上安装collectl,然后把性能信息实时发送到一个监控机器，实现grid control。当然，这里指的是安装了Linux操作系统的机器。

collectl支持的性能数据种类应该是最全的一个，包括IO/CPU/Network/NFS/Infiniband/Lustre/Process/Slabs等等。

最后贴一个collectl在Exadata上的一个应用，监控所有的8个数据库节点还有14个cell节点。

看起来Exadata V1的IO已经很强劲，对否？

collectl有一个工具colmux可以实现上面的类似功能，是collectl作者的另一个开源项目，叫Collectl Utilities(http://collectl-utils.sourceforge.net/)。

如果对上图监控方式感兴趣的朋友可以用邮件的方式和我进一步联系。